Good news, bad news

Ola Bini ola.bini at gmail.com
Wed May 25 03:37:34 PDT 2011 

Well, on my linux box with a JDK built this morning I don't see any of
these problems actually. (However, there are things on my master that
only works with the mlvm patches. Type conversions specifically.)

Problem 3 also seems to not be there - you would notice if it were since
it's also a total JVM crash. I do not see it on Linux with this version:
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build
1.7.0-internal-obini2_2011_05_25_03_33-b00)
OpenJDK 64-Bit Server VM (build 21.0-b13, mixed mode)

I built it from http://hg.openjdk.java.net/jdk7/jdk7 so it's not an
official drop, but it's not bsdport with mlvm either.

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
> 


-- 
 Ola Bini (http://olabini.com)
  Ioke - JRuby - ThoughtWorks

 "Yields falsehood when quined" yields falsehood when quined.

More information about the mlvm-dev mailing list