Still crashity crashing
Charles Oliver Nutter
headius at headius.com
Tue Aug 4 20:28:32 PDT 2009
The ShowMessageBox option also gave me the option of launching gdb.
I'm not a gdb expert, but "bt" produced this:
(gdb) bt
#0 0x96ebf3ae in __semwait_signal ()
#1 0x96f04398 in pthread_join$UNIX2003 ()
#2 0x0000668b in ContinueInNewThread0 ()
#3 0x0000440e in JLI_Launch ()
#4 0x0000d388 in main ()
Trying now to see if I can view stacks for other threads or something.
On Tue, Aug 4, 2009 at 10:24 PM, Charles Oliver
Nutter<headius at headius.com> wrote:
> 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.Ramakrishna at 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<headius at headius.com> wrote:
>>>> On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi<szegedia at 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 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
>>
>
More information about the mlvm-dev
mailing list