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

[Tom Rodriguez]

Yeah vladimir reported something similar to me last night.  I'm looking at it.

tom

On Aug 5, 2011, at 6:26 AM, Christian Thalinger wrote:

> 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
>> 
>