JDK-8312096 : C2: assert(false) failed: type flow analysis failed for OSR compilation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,21,22
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2023-07-14
  • Updated: 2024-01-13
  • Resolved: 2023-07-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Relates :  
JDK-8323692 - [premain] assert(false) failed: type flow analysis failed for OSR compilation
Relates :  
JDK-8303951 - Add asserts before record_method_not_compilable where possible
Description
When trying to run a replay file of a Java Fuzzer test, I've hit the following assertion:

Steps to reproduce:
$ mkdir test
$ cp r.log test

# Important: Only move Test.class to folder
$ cp Test.class test
$ cd test

# For versions before JDK 21 (i.e. before JDK-8303951 which added the failing assert), additionally add -XX:+AbortVMOnCompilationFailure
$ java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=r.log

With javac compilation:
$ mkdir test
$ cp r.log test
$ cp Test.java test
$ cp FuzzerUtils.java test
$ cd test
$ javac FuzzerUtils.java
$ javac Test.java

# Important: Remove FuzzerUtils.class again!
$ rm FuzzerUtils.class

# For versions before JDK 21 (i.e. before JDK-8303951 which added the failing assert), additionally add -XX:+AbortVMOnCompilationFailure
$ java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=r.log

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S74285/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d8f65403-2977-4b76-b632-b832f0f37873/runs/b69e6687-3d5f-4b09-9d2c-cf04294ff062/workspace/open/src/hotspot/share/opto/parse1.cpp:513), pid=846083, tid=846096
#  assert(false) failed: type flow analysis failed for OSR compilation
#
# JRE version: Java(TM) SE Runtime Environment (22.0+6) (fastdebug build 22-ea+6-377)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+6-377, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x14e3850]  Parse::Parse(JVMState*, ciMethod*, float)+0xd80
..........
Command Line: -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=r.log
..........
C2:     80   60 % !b  4       Test::vMeth @ 57 (332 bytes)

Stack: [0x00007fce5c0f5000,0x00007fce5c1f5000],  sp=0x00007fce5c1f19f0,  free space=1010k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x14e3850]  Parse::Parse(JVMState*, ciMethod*, float)+0xd80  (parse1.cpp:513)
V  [libjvm.so+0x850a28]  ParseGenerator::generate(JVMState*)+0x168
V  [libjvm.so+0x9f4106]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x16e6
V  [libjvm.so+0x84e63e]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x10e
V  [libjvm.so+0xa004e0]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00
V  [libjvm.so+0xa01368]  CompileBroker::compiler_thread_loop()+0x618
V  [libjvm.so+0xeb4c8c]  JavaThread::thread_main_inner()+0xcc
V  [libjvm.so+0x179114a]  Thread::call_run()+0xba
V  [libjvm.so+0x14918bc]  thread_native_entry(Thread*)+0x11c
Comments
Hi all, I also agree with you! And thank Christian for the detailed explanation!
26-07-2023
Thanks for the analysis, [~dqu]. I agree with Christian that this should be closed as "Not an Issue".
26-07-2023
Hi [~dqu], thanks for the analysis. I haven't looked at the failure in closer detail when I reported it. But it looks like it's a valid reason to hit the assertion failure with replay compilation in this particular case. As you've mentioned, in a normal run without replay compilation, we should not hit that assert. So, we should definitely keep that assert. One thing we could think about is changing the assert into: assert(ReplayCompiles, "type flow analysis failed for OSR compilation") Then it will only fire in non-compiler replay runs. But we then would miss it if there is a valid case where we should indeed hit it with replay compilation. Since this is quite an edge case and compiler replay often hits asserts when some classes are missing, we could also just close this as "Not an Issue". I think that might be the best option.
26-07-2023
This seems to be what happens after `FuzzerUtils.class` is removed: Following the directive of the replay log, an OSR compilation task for `Test::vMeth(byte by, int i, int i1)` is submitted. During compilation, a flow analysis starting from the beginning (i.e., bci is 0) of method `vMeth()` is first performed in `InlineTree::check_can_parse()`: https://github.com/openjdk/jdk/blob/c22cadf32fbfa206f089c9d73c3b7f3db069d47a/src/hotspot/share/opto/compile.cpp#L768-L769 Since class `FuzzerUtils` cannot be found, this flow analysis puts a trap in this line of `vMeth()`: ``` FuzzerUtils.init(dArr1, 0.112985); ``` and treats the subsequent lines as unreachable. But this OSR compilation starts from bci 57, which is the following line (after the trap mentioned above): ``` for (i25 = 1; i25 < 284; i25++) { ``` When this OSR flow analysis tries to retrieve the flow analysis result of the previous one, it only finds that the OSR bci is unreachable according to the previous result. This is shown by the following code: https://github.com/openjdk/jdk/blob/c22cadf32fbfa206f089c9d73c3b7f3db069d47a/src/hotspot/share/ci/ciTypeFlow.cpp#L374-L378 Then the following assertion is triggered. https://github.com/openjdk/jdk/blob/c22cadf32fbfa206f089c9d73c3b7f3db069d47a/src/hotspot/share/opto/parse1.cpp#L512-L514
26-07-2023
During normal compilation, this deserves an assertion fail because it indicates a bug. But during replay compilation, maybe we could report this kind of error and quit gracefully. I wonder if this is what you had in mind, Christian?
26-07-2023
ILW = Assert in OSR compiler replay compilation only affecting debug (bailout in product), single case, no workaround = MLH = P4
14-07-2023