review for 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods (original) (raw)

Christian Thalinger christian.thalinger at oracle.com
Mon Jul 11 08:43:41 PDT 2011

On Jul 9, 2011, at 12:21 AM, Tom Rodriguez wrote:

Coleen point out that it's confusing to reuse the name jumpfrominterpreted since we're not really in the interpreter. I've changed it to jumpfrommethodhandle and left that note that it parallels jumpfrominterpreted.

This looks good. Although I'm a little worried about the raise_exception changes on SPARC. In the past I had various crashes with versions that used the interpreter stack to pass the arguments. That's why I changed it to the simpler, more reliable current version (which uses the compiler calling convention). Maybe I got adjust_SP_and_Gargs_down_by_slots right and there is no problem now.

Just to be sure I'm currently running JRuby's benchmarks (my memory tells me that I had the crashes with these benchmarks) on two different SPARC boxes. I'll let you know when they are finished.

-- Christian

tom On Jul 8, 2011, at 1:10 PM, Tom Rodriguez wrote:

http://cr.openjdk.java.net/~never/6990212 154 lines changed: 117 ins; 19 del; 18 mod; 5215 unchg

6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Summary: check for single stepping when dispatching invokes from method handles Reviewed-by: Single stepping and method entry events requires some machinery in the interpreter to make sure that we never jump into compiled code but the method handle invoke path doesn't have that code. The fix is to reintroduce the required check and dispatch to the interpreted entry in that case. Tested with failing test cases from report plus a simple test case to exercise the MH raiseException path since I had to rewrite the arugment passing there.

More information about the hotspot-compiler-dev mailing list