Re: Testing out latest work
On Jul 14, 2012 12:35 AM, John Rose john.r.r...@oracle.com wrote: On Jul 13, 2012, at 4:04 PM, Charles Oliver Nutter wrote: I have run into my first obvious behavioral difference between the new and old code: the name argument (2nd arg) to bootstrap methods was interned under the old backend, but is not in the new backend. I don't know if there's anything in the spec to indicate it should be interned, but I figured I'd bring it up. It was the source of many test failures in JRuby because we had a key BSM that expected interned Strings. Oops, I'll intern the strings. I see no reason not to. It is slightly surprising when strings which originate in the constant pool are *not* interned. Yeah, that's where my expectation came from. Granted, the name alone is not found in the constant pool, but it still seemed like it should be interned. - Charlie (mobile) ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
Ok, updates. Still looking good on general stability. Perf is a mixed bag but still usually faster than non-indy. I have run into my first obvious behavioral difference between the new and old code: the name argument (2nd arg) to bootstrap methods was interned under the old backend, but is not in the new backend. I don't know if there's anything in the spec to indicate it should be interned, but I figured I'd bring it up. It was the source of many test failures in JRuby because we had a key BSM that expected interned Strings. I'm working my way through JRuby's jit.threshold=0 and AOT test suites, and so far that's the only indy-related issue. I'm looking into another test that seems to fail sporadically but only on MLVM. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
Charles, Am 12.07.2012 um 07:47 schrieb Charles Oliver Nutter: I pulled down all updates from today, did a fresh build, and things appear to be working properly. Hooray! :-) Perf isn't at u4 levels, but it isn't awful and stability seems pretty good...even including a few command lines that always triggered the dreaded NCDFE. Wonderful! Can you say some more about the performance? How much slower is it? Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
On Jul 11, 2012, at 10:47 PM, Charles Oliver Nutter wrote: I pulled down all updates from today, did a fresh build, and things appear to be working properly. Hooray! Hooray indeed! Now we are on the right track. Thanks (again) for joining us on the bleeding edge. — John___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
At 1:32 PM -0700 7/11/12, Charles Oliver Nutter wrote: Ok, gents, Christian told me now might be a good time to start poking at the new indy backend with JRuby, so I got a build together and have been playing with it a bit. First off, getting it to build... Stephen B's gist still works fine: https://gist.github.com/243072 But I had to issue one additional command to get xcode tools in the right places for command-line build of OpenJDK: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer This is latest Lion and Xcode (4.3.2). I previously installed the command-line tools through the Xcode interface. Thanks for the feedback. I fixed the BUILD location to reference the j2sdk-bundle in the script so when the result is copied to: ~/Library/Java/JavaVirtualMachines you get a JVM that shows up properly running: /usr/libexec/java_home --version 1.8 -V I also cleaned up the documentation in the comments and added the xcode-select -switch tip. https://gist.github.com/243072 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
FYI, this is a build from roughly 8AM CDT today. I don't think any patches have landed post-build. - Charlie On Wed, Jul 11, 2012 at 1:32 PM, Charles Oliver Nutter head...@headius.com wrote: Ok, gents, Christian told me now might be a good time to start poking at the new indy backend with JRuby, so I got a build together and have been playing with it a bit. First off, getting it to build... Stephen B's gist still works fine: https://gist.github.com/243072 But I had to issue one additional command to get xcode tools in the right places for command-line build of OpenJDK: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer This is latest Lion and Xcode (4.3.2). I previously installed the command-line tools through the Xcode interface. OK...so the next thing was getting the patches to apply. I essentially just disabled coro and removed -testable and -/meth from all meth-related patches. I'm not sure if this is the right list, but here's what actually applied before the build: https://gist.github.com/faf4437f5985828f3111 With that, I was able to build and things started to run. But not for long! :) First thing I tested was fib, and it ran incredibly slow...like 3 orders of magnitude slow. So I figured it must not be compiling. Turned on -XX:+PrintCompilation, got an AIOOB exception. Turned it off, consistently getting either segfaults or an AIOOB exception. Here's a couple dumps (exception during PrintCompilation, segfault, exception): https://gist.github.com/5ecfacea1a3f23ceaf9f So there it is for the moment :) Thoughts? - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
On Jul 11, 2012, at 1:35 PM, Charles Oliver Nutter wrote: So there it is for the moment :) Thoughts? Thanks for testing. Sorry it didn't get so far! I think we have a depot bug and/or race condition. It may be that more cores make the bug happen more. I am able to grind through things like bench/bench_red_black.rb in several modes, such as [1]. Yes, it is slow, so something is out of tune. We are going for correctness at the moment. — John [1] Is this a good test? $ JAVA_HOME=$JAVA8X_BUILD bin/jruby -J-Xbootclasspath/p:$METH_BUILD/classes -J-ea -J-esa -J-XX:+ShowMessageBoxOnError -J-showversion -J-d64 -J-Xbatch -J-XX:+TieredCompilation -J-XX:-UseCompressedOops -J-XX:+UnlockDiagnosticVMOptions -J-XX:+LogCompilation -J-XX:+PrintCompilation -X+C bench/bench_red_black.rb 4 15951b 3 java.lang.Integer::rotateLeft (9 bytes) 16052b 1 java.lang.Integer::rotateLeft (9 bytes) 16071 3 java.lang.Integer::rotateLeft (9 bytes) made not entrant 16093b 3 java.util.Hashtable::hash (48 bytes) Warning: TraceDependencies results may be inflated by VerifyDependencies openjdk version 1.8.0-internal OpenJDK Runtime Environment (build 1.8.0-internal-jrose_2012_07_08_02_30-b00) 16224 n 0 java.lang.System::arraycopy (native) (static) OpenJDK 64-Bit Server VM (build 24.0-b16-jvmg, mixed mode) 16335b 3 java.lang.Object::init (1 bytes) 16456b 3 java.lang.String::charAt (29 bytes) 16547b 3 java.lang.String::indexOf (70 bytes) 16678b 3 java.lang.String::length (6 bytes) 16699b 3 java.lang.Math::min (11 bytes) 1673 10b 3 java.lang.AbstractStringBuilder::ensureCapacityInternal (16 bytes) 1697 11b 3 java.lang.String::equals (81 bytes) 1749 12b 3 sun.misc.Hashing::murmur3_32 (188 bytes) 1777 13b 3 java.lang.CharacterData::of (120 bytes) 1785 14b 3 java.lang.CharacterDataLatin1::getProperties (11 bytes) 1817 15b 3 java.lang.String::init (67 bytes) 1839 16b 3 java.lang.String::getChars (62 bytes) 1852 17b 3 java.lang.AbstractStringBuilder::append (48 bytes) 1868 18b 3 java.lang.Character::toUpperCaseEx (30 bytes) ... 530728 2660b 4 java.util.IdentityHashMap::hash (18 bytes) 530733 1183 3 java.util.IdentityHashMap::hash (18 bytes) made not entrant 530734 2259 3 org.jruby.RubyObject$1::allocate (10 bytes) made zombie 530735 2265 3 org.jruby.runtime.callsite.CachingCallSite::call (50 bytes) made zombie 566829 2661b 4 java.lang.invoke.LambdaForm$MH/1997160570::guard (80 bytes) 567198 2651 3 java.lang.invoke.LambdaForm$MH/1997160570::guard (80 bytes) made not entrant 567201 2280 3 org.jruby.ast.executable.AbstractScript::setVariable2 (12 bytes) made zombie 567201 2279 3 org.jruby.ast.executable.AbstractScript::setVariable3 (12 bytes) made zombie 567201 2277 3 org.jruby.ast.executable.AbstractScript::setVariable1 (12 bytes) made zombie 567201 2276 3 org.jruby.ast.executable.AbstractScript::setVariable0 (12 bytes) made zombie 567206 2662b 4 java.lang.invoke.LambdaForm$MH/2083201325::guard (86 bytes) 567501 2652 3 java.lang.invoke.LambdaForm$MH/2083201325::guard (86 bytes) made not entrant 969865 2663b 1 java.util.Hashtable::access$600 (5 bytes) 970025 2278 3 org.jruby.ast.executable.AbstractScript::setVariable4 (12 bytes) made zombie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
On Wed, Jul 11, 2012 at 1:46 PM, John Rose john.r.r...@oracle.com wrote: Thanks for testing. Sorry it didn't get so far! I think we have a depot bug and/or race condition. It may be that more cores make the bug happen more. Oh yes, I should explain the system I'm on, in case it's relevant... OS X Lion, newish MBP, 4-core, 16GB memory. fib fails consistently in a variety of ways...NullPointer, ArrayIndex, ClassCast. Here's a few more traces: https://gist.github.com/4f72d09d0bb945801211 I am able to grind through things like bench/bench_red_black.rb in several modes, such as [1]. Yes, it is slow, so something is out of tune. We are going for correctness at the moment. Indeed...I don't expect to see performance at this point. I was just hoping to get JRuby green on the new work, and running these few benchmarks were my sanity test before I proceeded with that. red_black is a good benchmark, as are richards and neural. fib, tak, and base64 are nice simple numeric benchmarks. I was also able to run red_black for some time with your command line, but the same command line failed to run fib successfully. Recursion? Deep stacks? Happy to try anything or provide dumps or log output. My fib command line is generally: jruby JVM options bench/bench_fib_recursive.rb 10 35 - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
On Jul 11, 2012, at 2:12 PM, Charles Oliver Nutter wrote: OS X Lion, newish MBP, 4-core, 16GB memory. I have a 2009 MBP with 2 cores. We have a creeping suspicion that the crashing is more common on the 4-core machines. — John___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
On Jul 11, 2012, at 2:17 PM, John Rose wrote: On Jul 11, 2012, at 2:12 PM, Charles Oliver Nutter wrote: OS X Lion, newish MBP, 4-core, 16GB memory. I have a 2009 MBP with 2 cores. We have a creeping suspicion that the crashing is more common on the 4-core machines. I just fixed a problem that explains a lot of these intermittent failures (which I'm about to push after some sanity testing). And Charlie applied the xbmh patch which might explain some of the performance problems (just a wild guess). -- Chris — John ___ 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
Re: Testing out latest work
On Wed, Jul 11, 2012 at 2:42 PM, Christian Thalinger christian.thalin...@oracle.com wrote: I just fixed a problem that explains a lot of these intermittent failures (which I'm about to push after some sanity testing). And Charlie applied the xbmh patch which might explain some of the performance problems (just a wild guess). Still waiting on Christian's additional patch, but removing xbmh did not appear to help anything. Rebuilt, ran fib, and... system ~/projects/jruby $ jruby bench/bench_fib_recursive.rb 10 35 LambdaForm$BMH:-1:in `reinvoke': java.lang.ClassCastException: org.jruby.MetaClass cannot be cast to java.lang.invoke.BoundMethodHandle$Multiple from LambdaForm$DMH:-1:in `invokeStatic' from LambdaForm$BMH:-1:in `reinvoke' from LambdaForm$MH:-1:in `guard' from LambdaForm$DMH:-1:in `invokeSpecial' from LambdaForm$MH:-1:in `guard' from LambdaForm$MH:-1:in `linkToCallSite' None of these exceptions really make sense. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Testing out latest work
Updates! On Wed, Jul 11, 2012 at 3:04 PM, Charles Oliver Nutter head...@headius.com wrote: Still waiting on Christian's additional patch, but removing xbmh did not appear to help anything. Rebuilt, ran fib, and... I pulled down all updates from today, did a fresh build, and things appear to be working properly. Hooray! Perf isn't at u4 levels, but it isn't awful and stability seems pretty good...even including a few command lines that always triggered the dreaded NCDFE. Wonderful! Tomorrow I'll look at getting JRuby's jit immediately and AOT test runs green so we can start to use that as a sanity test for the new indy logic. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
