shenandoah c2 compiler crash in jdk8

[Roland Westrelin]

> 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

Thanks. I'm surprised the assert and the crash are related. The assert
catches the IR graph growing too big. That in itself shouldn't cause a
crash in the release build. I suppose the release build crash doesn't
reproduce once the node limit is bumped? Maybe that hides the bug rather
than work around it.

One way to reproduce the issues is by using replay compilation. The VM
should have dumped replay_pid files for the 2 crashes. Running:

java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pidxxx.log -XX:+ReplayIgnoreInitErrors

with the same classpath and compile time option as the actual runs is
often all it takes to reproduce the crash. The VM needs to find every
class that's mentioned in the replay file (it's a text file so you can
look into it).

If that works then and you were willing to share the class files I
should be able to reproduce it as well.

Roland.