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

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 jump_from_interpreted since we're not really in the interpreter.  I've changed it to jump_from_method_handle and left that note that it parallels jump_from_interpreted.

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