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

[David Holmes]

Hi Erik,

Sorry I hadn't had a chance to get back to this. This new approach seems 
fine - though I had to convince myself of the no GC can occur part :)

A couple of typos:

JvmtiBreakpoint:s

The :s should just be s

Thanks,
David

On 21/10/2013 7:26 PM, Erik Helin wrote:
> 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
>