Still crashity crashing
Charles Oliver Nutter
headius at headius.com
Tue Aug 4 20:24:49 PDT 2009
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_err_pid43068.log
Type: application/octet-stream
Size: 7514 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090804/b28b9fd0/attachment.obj
More information about the mlvm-dev
mailing list