JDK-8360521 : Assertion is triggered: type flow analysis failed during parsing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: ppc
  • Submitted: 2025-06-25
  • Updated: 2025-06-30
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
tbdUnresolved
Related Reports
Relates :  
JDK-8303951 - Add asserts before record_method_not_compilable where possible
Description
When running some benchmarks with a fastdebug build an assertion is triggered in most cases:

```
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/**********/jdk/src/hotspot/share/opto/parse1.cpp:521), pid=3049929, tid=3050028
#  assert(false) failed: type flow analysis failed during parsing
```

It seems that https://bugs.openjdk.org/browse/JDK-8303951 is the origin of that assertion.

I cannot share the code for the benchmark but I have attached the hs_err file.
Comments
I cannot reproduce it that way. I run into the following errors: Error while parsing line 1626 at position 54: constant pool length mismatch: wrong class files? Error while parsing line 1627 at position 65: $assertionsDisabled Error while parsing line 1628 at position 68: constant pool length mismatch: wrong class files? Error while parsing line 1630 at position 60: constant pool length mismatch: wrong class files? Error while parsing line 1631 at position 66: constant pool length mismatch: wrong class files? Error while parsing line 1632 at position 77: $assertionsDisabled and more.
30-06-2025
Can you reproduce this with replay compilation and your old rt7.jar? I.e. with something like 'java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid3049929.log -cp rt7.jar' ILW = Assert during C2 compilation (harmless bailout in product), modified benchmark with old rt.jar, no workaround but disable compilation of affected method = MLH = P4
27-06-2025
I see, that explains the inconsistent information in the replay file then. The method that fails compilation is from a very old JDK 7: https://github.com/openjdk/jdk7/blob/f57b87e8f6b8ca9e3c1e640dca51c2a18ee1ef6a/langtools/src/share/classes/com/sun/tools/javac/comp/Flow.java#L1251
27-06-2025
It is also worth mentioning, that the compiler benchmark was modified to use "rt7.jar" which is copied from a JDK7 to same directory as SPECjvm2008.jar. This is needed to run with later JDK versions.
26-06-2025
Thanks. Yes, we run that benchmark on a regular basis here but haven't observed this issue. The method that fails compilation is 'com.sun.tools.javac.comp.Flow::analyzeTree' which is not part of the benchmark. However, I see from the replay that the signature of the method is '(Lcom/sun/tools/javac/tree/JCTree;Lcom/sun/tools/javac/tree/TreeMaker;)V' which seems to differ from https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java Do you have any changes in that code? Also, I see that you are running with -XX:+UseNewCode?
26-06-2025
I uploaded the replay but I cannot share the class files / sources. Are you in possession of the jvm2008 benchmark?
26-06-2025
I've seen this in Valhalla before and there the root cause was a trap added in ciTypeFlow::StateVector::do_invoke. Maybe it's something similar here.
26-06-2025
[~dbriemann] JDK-8303951 just added asserts, you should be able to reproduce this even before with -XX:+AbortVMOnCompilationFailure. Is this ppc specific? Do you have a reproducer? Could you share the replay file?
26-06-2025
The new code was only some stats printing. I just tested with master branch and encountered the same assertion. This is on a Power9 machine.
26-06-2025