Still crashity crashing

[Y.S.Ramakrishna at Sun.COM]

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