RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2)
erik.helin at oracle.com
Mon Oct 21 02:26:51 PDT 2013
this is the second version of a patch for JDK-8025834.
In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a
JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an
"unhandled" oop to the class loader of the Method's class.
A pointer to the JvmtiBreakpoint allocated on the stack will be passed
to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The
VM_ChangeBreakpoint class has an oops_do method that will visit the oop
in the JvmtiBreakpoint that was allocated on the stack.
Since no GC can occur before the JvmtiBreakpoint has been passed to the
VM_ChangeBreakpoint (which is then passed to VMThread::execute), there
is no need to have a Handle for the _class_loader oop. Once the
VM_ChangeBreakpoint is on the VMThread's list for being executed, the
oop will be found via VMThread::oops_do.
The oop can't be changed to a Handle because JvmtiBreakpoint:s are also
allocated on the heap, and Handles are only used for oops allocated on
This patch therefore registers the oop as "unhandled" to tell the
unhandled oop verifier to (rightfully) ignore it.
As I explained in a previous email, there are additional issues in the
JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods:
This change does not intend to fix these issues.
More information about the hotspot-dev