RFR: JDK-8318445: More broken bailout chains in C2

[Emanuel Peter]

On Wed, 18 Oct 2023 14:48:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> More places where, after a node limit check, we did not bail out properly.
> 
> 
> Crash:
> 
> Current CompileTask:
> C2:2574 45 45 843 4 sun.nio.fs.UnixPath::resolve (17 bytes)
> 
> Stack: [0x00007fa608cb3000,0x00007fa608db4000], sp=0x00007fa608daf310, free space=1008k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x631bb4] Unique_Node_List::push(Node*)+0x20 (node.hpp:1650)
> V [libjvm.so+0xb8ea65] ConnectionGraph::verify_ram_nodes(Compile*, Node*)+0x87 (escape.cpp:743)
> V [libjvm.so+0x960dda] Compile::Optimize()+0x956 (compile.cpp:2361)
> V [libjvm.so+0x959d6c] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x165e (compile.cpp:860)
> V [libjvm.so+0x81bcd9] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x203 (c2compiler.cpp:134)
> V [libjvm.so+0x97bf63] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xac5 (compileBroker.cpp:2290)
> V [libjvm.so+0x97a981] CompileBroker::compiler_thread_loop()+0x411 (compileBroker.cpp:1951)
> V [libjvm.so+0x99ebc0] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x84 (compilerThread.cpp:61)
> V [libjvm.so+0xde0050] JavaThread::thread_main_inner()+0x15c (javaThread.cpp:720)
> V [libjvm.so+0xddfeea] JavaThread::run()+0x258 (javaThread.cpp:705)
> V [libjvm.so+0x15f5a04] Thread::call_run()+0x1a8 (thread.cpp:220)
> V [libjvm.so+0x12de0a2] thread_native_entry(Thread*)+0x1c3 (os_linux.cpp:785)
> 
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000028
> 
> Pending compilation failure details for thread 0x00007fa5b8003140:
>   Time: 2.545243 seconds (0d 0h 0m 2s) Compile id: 843
>   Reason: 'hit memory limit while compiling'
>   Callstack:[0x00007fa64262bd64] Compile::record_method_not_compilable(char const*)+0x4a
> [0x00007fa6428be4d5] Compile::record_method_not_compilable_oom()+0x27
> [0x00007fa6427c7130] Compile::check_node_count(unsigned int, char const*)+0x34
> [0x00007fa64329bb06] PhaseIterGVN::optimize()+0xaa
> [0x00007fa6428b2d75] Compile::Optimize()+0x8f1
> [0x00007fa6428abd6c] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x165e
> [0x00007fa64276dcd9] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x203
> [0x00007fa6428cdf63] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xac5
> [0x00007fa6428cc981] CompileBroker::compiler_thread_loop()+0x411
> [0x00007fa6428f0bc0] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x84
> [0x00007fa642d32050] JavaThread::thread_main_inner()+0x15c
> [0x00007fa642d31eea...

@tstuefe Thanks for the fix. Yes, it seems we should catch failure after any igvn phase.

What exactly causes the crash? I guess we have somehow a messed up graph, want to bail out but then do not bail out but instead go back into some optimization, and then encounter the broken graph?

I guess we could catch this with some sort of stress testing: randomly decide to mess up the graph and bail out. Then we will see if every place really processes the bailout correctly. @vnkozlov what do you think?

@vnkozlov should we file any RFE's?

Do you have a reproducer for this? I see none here and none on JBS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16248#issuecomment-1772123096