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

[Christian Thalinger]

I really had this feeling that this change is going to break something.  Two JDK tests are failing on x86 and SPARC:

FAILED: java/lang/invoke/JavaDocExamplesTest.java
FAILED: java/lang/invoke/MethodHandlesTest.java

It's the raise_exception path:

JUnit version 4.4
.......................................E.E.
Time: 1.767
There were 2 failures:
1) testInterfaceCast(test.java.lang.invoke.MethodHandlesTest)
java.lang.InternalError: unexpected code -38348624: required class java.lang.Number but encountered class java.lang.String
        at java.lang.invoke.MethodHandleNatives.raiseException(MethodHandleNatives.java:375)
        at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566)
        at test.java.lang.invoke.MethodHandlesTest.testInterfaceCast(MethodHandlesTest.java:2231)
        at test.java.lang.invoke.MethodHandlesTest.testInterfaceCast(MethodHandlesTest.java:2208)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
        at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
        at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
        at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
        at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
        at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
        at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
        at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
        at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
        at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
        at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
        at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
        at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33)
        at org.junit.internal.runners.CompositeRunner.run(CompositeRunner.java:28)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:130)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:109)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:100)
        at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81)
        at org.junit.runner.JUnitCore.main(JUnitCore.java:44)
2) testCastFailure(test.java.lang.invoke.MethodHandlesTest)
java.lang.InternalError: unexpected code -38348480: required class java.lang.Integer but encountered class java.lang.String
        at java.lang.invoke.MethodHandleNatives.raiseException(MethodHandleNatives.java:375)
        at test.java.lang.invoke.MethodHandlesTest.testCastFailure(MethodHandlesTest.java:2340)
        at test.java.lang.invoke.MethodHandlesTest.testCastFailure(MethodHandlesTest.java:2251)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
        at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
        at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
        at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
        at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
        at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
        at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
        at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
        at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
        at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
        at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
        at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
        at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33)
        at org.junit.internal.runners.CompositeRunner.run(CompositeRunner.java:28)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:130)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:109)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:100)
        at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81)
        at org.junit.runner.JUnitCore.main(JUnitCore.java:44)

FAILURES!!!
Tests run: 41,  Failures: 2

-- Christian

On Jul 14, 2011, at 9:49 PM, Tom Rodriguez wrote:

> 
> On Jul 12, 2011, at 9:38 AM, Christian Thalinger wrote:
> 
>> On Jul 11, 2011, at 5:43 PM, Christian Thalinger wrote:
>>> 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.
>> 
>> Sorry, it took a little longer to run them because one of the benchmarks (bench_full_load_path.rb) does not finish (it hangs around doing nothing).  Anyway, all others look good.
> 
> Thanks.  I fixed the interp_only check to look more like the original code and reran the mlvm tests and they all look good.
> 
> tom
> 
>> 
>> -- Christian
>