RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2)

[Erik Helin]

Hi all,

this is the second version of a patch for JDK-8025834.

Background:
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
the stack.

This patch therefore registers the oop as "unhandled" to tell the
unhandled oop verifier to (rightfully) ignore it.

Webrev:
http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8025834

As I explained in a previous email, there are additional issues in the
JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods:
- https://bugs.openjdk.java.net/browse/JDK-8026946
- https://bugs.openjdk.java.net/browse/JDK-8026948
This change does not intend to fix these issues.

Thanks,
Erik