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