Here's the output with the verify flags on: ~/projects/jruby ➔ jruby -J-XX:+UnlockDiagnosticVMOptions -J-XX:+VerifyBeforeGC -J-XX:+VerifyAfterGC -J-Djruby.compile.invokedynamic -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 [Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyAfterGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyAfterGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyAfterGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads #
The hs_err file is attached. I do not have pstack on OS X...do you know what the equivalent would be? On Tue, Aug 4, 2009 at 8:56 PM, <y.s.ramakris...@sun.com> wrote: > The crash is in GC. Together with yr conjecture that the crash happens > after a while when you expect the method to have been jitted, this might > imply that the jit is not correctly conveying to GC where the > references in jitted frames are or is not marking cards for the > generational collector correctly, or GC isn't looking at all the > slots it should be looking at or .... (But that is a long assumption.) > The funny part about "running long enough" is that the hs_err log > says the crash occurred after 0 seconds, so the VM is probably > not correctly printing the time it's been running. > > I'd suggest running the JVM with the options -XX:+VerifyBeforeGC and > -XX:+VerifyAfterGC > to perhaps catch the problem sooner or get closer to the root cause. > If you run with the additional JVM option -XX:+ShowMessageBoxOnError > you might be able to pstack the process and get some info. (Or > use the hs_err script to decode the stack trace from the hs_err log.) > > -- ramki > > On 08/04/09 18:07, Charles Oliver Nutter wrote: >> I can't seem to catch a break. My local build and Attila's build still >> both crash for me. There's got to be something about my environment >> that's different, eh? >> >> As before, interpreter runs fine. Anything that runs long enough to >> jit seems to crash. I've attached the latest log. >> >> On Tue, Aug 4, 2009 at 7:58 PM, Charles Oliver >> Nutter<head...@headius.com> wrote: >>> On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi<szege...@gmail.com> wrote: >>>> I can now confirm that it indeed does work with jruby-1.4.0dev that >>>> indeed emits invokedynamic. >>>> >>>> The only catch is, it's very slow with invokedynamic, something that >>>> Christian also mentioned. >>> The fact that these numbers are so bad and even degrade shows me that >>> although it's compiling indy, it's not eliminating the handles (which >>> is true, the inlining and handle-walking stuff is not ready yet). So >>> it's got many layers of polymorphic calls, probably some argument >>> boxing and unboxing, and basically a ton more overhead than our >>> heavily tuned non-indy call path. I'm confident in the Hotspot guys :) >>> >>> Just wanted to make sure anyone watching didn't think this was the >>> best it would get... >>> >>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- >>>> Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ >>>> bench_fib_recursive.rb 15 >>>> 2.993000 0.000000 2.993000 ( 2.915000) >>>> 2.720000 0.000000 2.720000 ( 2.720000) >>>> 2.773000 0.000000 2.773000 ( 2.773000) >>>> 2.712000 0.000000 2.712000 ( 2.712000) >>>> 3.057000 0.000000 3.057000 ( 3.057000) >>>> 3.183000 0.000000 3.183000 ( 3.184000) >>>> 3.167000 0.000000 3.167000 ( 3.167000) >>>> 3.145000 0.000000 3.145000 ( 3.145000) >>>> 3.249000 0.000000 3.249000 ( 3.249000) >>>> 3.160000 0.000000 3.160000 ( 3.160000) >>>> 3.104000 0.000000 3.104000 ( 3.104000) >>>> 3.152000 0.000000 3.152000 ( 3.153000) >>>> 3.172000 0.000000 3.172000 ( 3.171000) >>>> 3.111000 0.000000 3.111000 ( 3.111000) >>>> 3.201000 0.000000 3.201000 ( 3.201000) >>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ >>>> bench_fib_recursive.rb 15 >>>> 0.523000 0.000000 0.523000 ( 0.481000) >>>> 0.292000 0.000000 0.292000 ( 0.291000) >>>> 0.279000 0.000000 0.279000 ( 0.278000) >>>> 0.283000 0.000000 0.283000 ( 0.283000) >>>> 0.284000 0.000000 0.284000 ( 0.284000) >>>> 0.292000 0.000000 0.292000 ( 0.292000) >>>> 0.289000 0.000000 0.289000 ( 0.289000) >>>> 0.286000 0.000000 0.286000 ( 0.287000) >>>> 0.285000 0.000000 0.285000 ( 0.285000) >>>> 0.285000 0.000000 0.285000 ( 0.285000) >>>> 0.289000 0.000000 0.289000 ( 0.290000) >>>> 0.282000 0.000000 0.282000 ( 0.282000) >>>> 0.290000 0.000000 0.290000 ( 0.290000) >>>> 0.293000 0.000000 0.293000 ( 0.293000) >>>> 0.285000 0.000000 0.285000 ( 0.284000) >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >
hs_err_pid43068.log
Description: Binary data
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
