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
