Good news, bad news
Christian Thalinger
christian.thalinger at oracle.com
Wed May 25 03:23:54 PDT 2011
On May 25, 2011, at 12:20 PM, Ola Bini wrote:
> Hi,
>
> Just to clarify, my builds are against the current patchset in the MLVM
> repository, so that might explain why you're not seeing these problems.
I know that. That's why we need to find out where the problem is (some hints below). Can someone provide a jar file of the current MLVM JSR 292 classes (like John's meth.jar)?
-- Christian
>
> Cheers
>
> On 2011-05-25 14.29, Christian Thalinger wrote:
>> On May 25, 2011, at 5:58 AM, Ola Bini wrote:
>>> Hi,
>>>
>>> There are at least three problems that are still there. They might be
>>> connected, or not.
>>> (I will tell you how to reproduce these at the end)
>>>
>>> I just built a new JVM:
>>> openjdk version "1.7.0-internal"
>>> OpenJDK Runtime Environment (build
>>> 1.7.0-internal-olabini_2011_05_25_08_06-b00)
>>> OpenJDK Server VM (build 21.0-b09, mixed mode)
>>>
>>> I get that weird missing class error when running my test suite:
>>> java.lang.NoClassDefFoundError: seph/lang/SephObject
>>> java.lang.RuntimeException: java.lang.NoClassDefFoundError:
>>> seph/lang/SephObject
>>> at seph.lang.Runtime.evaluateStream(Runtime.java:132)
>>> at seph.lang.Runtime.evaluateString(Runtime.java:146)
>>> at
>>> seph.lang.code.BasicSanityTest.recursive_odd_and_even_that_should_blow_the_stack(BasicSanityTest.java:214)
>>> Caused by: java.lang.NoClassDefFoundError: seph/lang/SephObject
>>> at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java)
>>> at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java)
>>> at seph$gen$abstraction$41$even?.argument_0_0(<eval>:7)
>>> at seph.lang.compiler.Bootstrap.intrinsic_if(Bootstrap.java:654)
>>> at seph$gen$abstraction$41$even?.even?(<eval>:7)
>>> at seph$gen$abstraction$39$toplevel.toplevel(<eval>:25)
>>> at seph.lang.Runtime.evaluateStream(Runtime.java:125)
>>>
>>> This is obviously a complete blocker.
>>>
>>> Turning off the ricochet frames hits an NYI error when running the test
>>> suite.
>>>
>>> I'm still seeing a crash in ricochet frames:
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> # SIGBUS (0xa) at pc=0x0104884f, pid=85043, tid=2953850880
>>> #
>>> # JRE version: 7.0
>>> # Java VM: OpenJDK Client VM (21.0-b09 mixed mode bsd-x86 )
>>> # Problematic frame:
>>> # V [libjvm.dylib+0x4884f] MethodHandles::ricochet_frame_oops_do(frame
>>> const&, OopClosure*, RegisterMap const*)+0x12f
>>> #
>>> # Failed to write core dump. Core dumps have been disabled. To enable
>>> core dumping, try "ulimit -c unlimited" before starting Java again
>>> #
>>> # An error report file with more information is saved as:
>>> # /Users/olabini/workspace/seph/hs_err_pid85043.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> # http://bugreport.sun.com/bugreport/crash.jsp
>>> #
>>>
>>> I've attached the error file.
>>>
>>> The third error (in frame.cpp) only happens on master of seph, but there
>>> are some other problems with master that means you get lots of weird output.
>>>
>>> In order to reproduce problem 1 and 2:
>>> git clone git://github.com/seph-lang/seph.git
>>> git checkout 9075c0f4ffe1adac0657057aee2193f16ad12a43
>>> (build.xml: remove lines with <jvmarg value="-Xint"/>)
>>>
>>> problem 1:
>>> ant
>>> This should show you one entry of the missing class problem
>>
>> I tried this on solaris-i586 and it works:
>>
>> BUILD SUCCESSFUL
>> Total time: 29 seconds
>>
>>>
>>> problem 2:
>>> ant jar-notest
>>> bin/seph bench/bench_arithmetic.sp
>>> This should show you problem 2.
>>> If you for reference want to see the benchmark run correctly, do
>>> bin/seph -J-Xint bench/bench_arithmetic.sp
>>
>> Works too (with server compiler on b143).
>>
>>>
>>> problem 3:
>>> git checkout master
>>> git checkout 99c8f2609d468835390e39b68c73f21cc78e5ab5
>>> ant clean jar-notest
>>> bin/seph bench/bench_arithmetic.sp
>>> This should show you problem 3. You will also see loads of other
>>> exceptions, since that point generates slightly bad bytecode. That
>>> shouldn't make the JVM crash though, I assume - and I've seen the
>>> frame.cpp should not reach here without seeing those exceptions.
>>
>> I think I see the exception you are talking about but there is so much output that I'm not sure.
>>
>> I curious about where the problem lies, either it's a HotSpot fix that's not in the mlvm repository yet or it's a JDK bug in one of the mlvm patches which hasn't been pushed yet into the main repository. At least that's my best guess.
>>
>> May I suggest that you guys also try with an official build (like JDK 7 b143) from here (assuming everyone has some kind of access to a Linux box too):
>>
>> http://jdk7.java.net/download.html
>>
>> -- Christian
>>
>>>
>>> All of these require that JAVA_HOME points to the Java 7 you want to use
>>>
>>> Cheers
>>>
>>>>
>>>> tom
>>>>
>>>> On May 23, 2011, at 7:33 PM, Ola Bini wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm happy to see that the performance degradation is getting
>>>>> addressed. I would like to point out that there is still a serious
>>>>> crash in the machinery too... Have you seen any reason why that
>>>>> happens?
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> On 2011-05-24 06.11, John Rose wrote:
>>>>>> On May 23, 2011, at 3:44 PM, Tom Rodriguez wrote:
>>>>>>
>>>>>>>> I'd *love* for intermediate static Java snippits like this
>>>>>>>> to inline straight through, even if invokeExact would be
>>>>>>>> megamorphic under normal circumstances...but I don't think
>>>>>>>> that's the case right now, right?
>>>>>>>
>>>>>>> I haven't been following 292 that closely but it used to be a
>>>>>>> piece of code that did precisely that.
>>>>>>>
>>>>>>> + private Object invoke_L0() throws Throwable { + if
>>>>>>> ((boolean) test.invokeExact()) + return
>>>>>>> target.invokeExact(); + return
>>>>>>> fallback.invokeExact(); + }
>>>>>>>
>>>>>>> It looks like it was reworked at some point to use
>>>>>>> selectAlternative but the optimizer was never updated to deal
>>>>>>> with it properly. It's not particularly hard, we just need to
>>>>>>> generate code like we would for a bimorphic call site. The
>>>>>>> current code expects to either get a constant or something else
>>>>>>> and doesn't inline if it's something else. In this case we
>>>>>>> have a Phi of two constants which we just need to split.
>>>>>>
>>>>>> Yes, it would be a quasi-bimorphic call site keyed from a phi of
>>>>>> two constants, instead of a profile of two receiver classes.
>>>>>>
>>>>>>> I'm still unclear why you couldn't write your own variant of
>>>>>>> guardWithTest and have it work but my knowledge of what's
>>>>>>> really allowed is somewhat limited.
>>>>>>
>>>>>> Those snippets will inline (I think), but at some point Charlie
>>>>>> will want to fetch a bit of constant stuff out of an instance
>>>>>> variable. That will look non-constant to the optimizer, even if
>>>>>> the instance variable is final and the enclosing object is a
>>>>>> constant reference. We made sure this happens for
>>>>>> java.lang.invoke classes, but we haven't extended it yet to user
>>>>>> code, in part because it would have its own bug tail to work
>>>>>> through.
>>>>>>
>>>>>> -- John _______________________________________________ mlvm-dev
>>>>>> mailing list mlvm-dev at openjdk.java.net
>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>>
>>>>>
>>>>>
>>>>> -- Ola Bini (http://olabini.com) Ioke - JRuby - ThoughtWorks
>>>>>
>>>>> "Yields falsehood when quined" yields falsehood when quined.
>>>>>
>>>>> _______________________________________________ mlvm-dev mailing
>>>>> list mlvm-dev at openjdk.java.net
>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>
>>>> _______________________________________________ mlvm-dev mailing
>>>> list mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
More information about the mlvm-dev
mailing list