shenandoah c2 compiler crash in jdk8

[Nick Evgeniev]

hi,

Just a bit more info -- w/o Shenandoah I can push that limit safely to just
3k before replay starts crashing.. So, substantially is a weak word...
unless it's a bug Shenandoah needs 30x more nodes. Hope it helps

On Mon, 2 Nov 2020 at 14:02, Nick Evgeniev <nevgeniev at gmail.com> wrote:

> hi,
>
> I'll try to come up with sample code, not sure to what degree compilation
> 'context' is critical. But if you have some build to try (with more
> logging/tracing) i'm more than willing to help... Also i've tried to bump
> up in steps 75k->80k->90k->100k. It fails everywhere in between. for 80k it
> fails in Node::req()
>
> I think that the qn that needs to be answered is whether there is a `leak`
> in nodes or you just need more of them. Does that make sense? If so, is
> there an option to dump c2 node usage over time?
>
> also just in case there is original stack trace (from release build w/o
> assertions):
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0x4b6eae]  Compile::final_graph_reshaping()+0x1e
> V  [libjvm.so+0x4b923e]  Compile::Optimize()+0xd8e
> V  [libjvm.so+0x4bb217]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*,
> int, bool, bool, bool)+0x11c7
> V  [libjvm.so+0x40fd8c]  C2Compiler::compile_method(ciEnv*, ciMethod*,
> int)+0x20c
> V  [libjvm.so+0x4c2096]
>  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd46
> V  [libjvm.so+0x4c4977]  CompileBroker::compiler_thread_loop()+0x657
> V  [libjvm.so+0xb22981]  JavaThread::thread_main_inner()+0xf1
> V  [libjvm.so+0x9674a2]  java_start(Thread*)+0x132
> C  [libpthread.so.0+0x7ea5]  start_thread+0xc5
>
>
> On Mon, 2 Nov 2020 at 02:32, Roland Westrelin <rwestrel at redhat.com> wrote:
>
>>
>> Hi,
>>
>> > It stops crashing if I add `-XX:MaxNodeLimit=100000` option.. Is it true
>> > that Shenandoah needs substantially more nodes compared to CMS? If so,
>> > default (75000) probably needs to be adjusted... as crash in release
>> > version has less than obvious stacktrace
>> >
>> > Pls confirm it's not a bug :)
>>
>> I'm not sure bumping MaxNodeLimit is the best way to fix this. Would
>> there be a way for us to reproduce the crash?
>>
>> Roland.
>>
>>