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@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@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ mlvm-dev mailing >> list mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
