There were some naked oops found and fixed during development of the unhandled oop detector. These fixes should be backported to an update release.

http://jruntime.east/~coleenp/webrev/4816341_cleanups/src/share/vm/prims/jvmtiImpl.hpp.diff.html

jvmtiError
JvmtiEnv::GetLocalObject(JavaThread* java_thread, jint depth, jint slot, jobject* value_ptr) {
  VM_GetOrSetLocal op(java_thread, depth, slot, T_OBJECT);
  VMThread::execute(&op); <-- safepoint
  jvmtiError err = op.result();
  if (err != JVMTI_ERROR_NONE) {
    return err;
  } else {
    oop obj = op.oop_value(); <- oop_value can be GC'ed
    *value_ptr = jni_reference(((Handle)obj)());
    return JVMTI_ERROR_NONE;
  }
} /* end GetLocalObject */

VM_GetOrSetLocal needs an oops_do()

In:

http://jruntime.east/~coleenp/webrev/4816341_cleanups/src/share/vm/prims/jvmtiExport.cpp.diff.html

  jmethodID to_jmethodID(methodOop method) { return method->jmethod_id(); }

can eventually take out the lock JNIIdentifier_lock in jniIDCreator::mid() so
method is an unsafe oop.

In:

http://jruntime.east/~coleenp/webrev/4816341_cleanups/src/share/vm/prims/jvmtiTagMap.cpp.diff.html

void JvmtiTagMap::iterate_over_instances_of_class(klassOop k_oop...
{
  MutexLocker ml(Heap_lock);
  IterateOverHeapOperation op(this, _k_oop, object_filter, heap_object_callback, user_data);
  VMThread::execute(&op);
}

k_oop is unsafe because the Heap_lock can cause GC.

There were 2 naked oops in other code:

http://jruntime.east/~coleenp/webrev/4816341_cleanups/src/share/vm/ci/ciEnv.cpp.diff.html

In get_klass_by_index_impl klass is unsafe because it's used after the acquisition of the lock
      ObjectLocker ol(cpool, THREAD);
in the same function.

http://jruntime.east/~coleenp/webrev/4816341_cleanups/src/share/vm/memory/universe.cpp.diff.html

There was an oop k used after link_class() which can take out a lock.

These are already fixed in mustang.
###@###.### 2005-05-03 20:26:37 GMT
###@###.### 2005-05-03 23:39:19 GMT


After much discussion, it was decided that the naked oop found in
ciEnv.cpp was an artifact of the early naked oop detector and not
an actual naked oop. The other naked oops mentioned should be
back ported.

###@###.### 2005-06-07 04:09:50 GMT


Alan Bateman pointed out another naked oop problem that was fixed in
Mustang via the following bug:

    6264760 3/4 potential naked oop issue with Set/ClearBreakpoints

I'm adding that fix to the backport collection.

###@###.### 2005-06-14 21:47:15 GMT