Erik, On Monday 21 October 2013 11.26.51 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/
The change looks good to me. /Mikael > > 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
