RFR: JDK-8318444: Write details about compilation bailouts into crash reports [v2]

[Tobias Hartmann]

On Fri, 20 Oct 2023 07:13:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> A little debugging aid to help analyze broken bailout chains, mainly in C2 (C1 is pretty clean).
>> 
>> A broken bailout chain occurs when code marks a compilation as failed, but then either that function itself or any of its caller functions fails to abort the compilation. That may cause crashes, e.g. [JDK-8318183](https://bugs.openjdk.org/browse/JDK-8318183) or [JDK-8318445](https://bugs.openjdk.org/browse/JDK-8318445).
>> 
>> Now, if the compiler initiates a bailout, it stores some context information - compile id, time, and call stack. That information is stored as part of `Compile` or `Compilation`, depending on the compiler.
>> 
>> If we crash later during the same compilation, we print out that information as part of the crash report. That way, we have two call stacks, and it is easy to spot where the compiler failed to heed the bailout.
>> 
>> ---------
>> 
>> Looks like this (from https://github.com/openjdk/jdk/pull/16248). The first call stack is the crash point. The second call stack is the point where the compiler bailout was initiated. 
>> 
>> 
>> 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...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reinstate elapsed time prefix in hs-err file

That looks good to me but someone more familiar with error reporting should have a look as well. I submitted some testing and will report back once it passed.

src/hotspot/share/compiler/compilationFailureInfo.hpp line 49:

> 47: 
> 48:   // Convenience function to print, safely, current compile failure iff
> 49:   // current thread is compiler thread and there is a ongoing compilation

Suggestion:

  // current thread is compiler thread and there is an ongoing compilation

src/hotspot/share/utilities/vmError.cpp line 1054:

> 1052: #if defined(COMPILER1) || defined(COMPILER2)
> 1053:   STEP_IF("printing pending compilation failure",
> 1054:          _verbose && _thread != nullptr && _thread->is_Compiler_thread())

Suggestion:

          _verbose && _thread != nullptr && _thread->is_Compiler_thread())

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16247#pullrequestreview-1699601135
PR Review Comment: https://git.openjdk.org/jdk/pull/16247#discussion_r1373149693
PR Review Comment: https://git.openjdk.org/jdk/pull/16247#discussion_r1373148266