JDK-8303951 : Add asserts before record_method_not_compilable where possible
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-03-10
  • Updated: 2024-05-21
  • Resolved: 2023-03-23
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.
JDK 21
21 b16Fixed
Related Reports
Relates :  
JDK-8303466 - C2: failed: malformed control flow. Limit type made precise with MaxL/MinL
Relates :  
JDK-8332632 - Redundant `assert(false, "compiler should always document failure: %s"...`
Relates :  
JDK-8306997 - C2: "malformed control flow" assert due to missing safepoint on backedge with a switch
Relates :  
JDK-8304328 - C2 Bailout "failed spill-split-recycle sanity check" reveals hidden issue with RA
Relates :  
JDK-8288981 - C2: Fix issues with skeleton predicates
Relates :  
JDK-8304532 - Add asserts before C1 BAILOUT
Relates :  
JDK-8308392 - [Umbrella] C2: assert(false) failed: malformed control flow
Relates :  
JDK-8328078 - C2 compilation bailout with "too many D-U pinch points"
Relates :  
JDK-8307131 - C2: assert(false) failed: malformed control flow
Relates :  
JDK-8309353 - [lworld] C2 compilations fails with assert(false) failed: type flow analysis failed for OSR compilation
Relates :  
JDK-8325095 - C2: bailout message broken: ResourceArea allocated string used after free
Relates :  
JDK-8313241 - Temporarily disable "malformed control flow" assert to reduce noise
Relates :  
JDK-8305185 - C2 failed "assert(false) failed: Can't determine return type."
Relates :  
JDK-8312096 - C2: assert(false) failed: type flow analysis failed for OSR compilation
Relates :  
JDK-8324743 - C2 can't compile method with nested locks
Relates :  
JDK-8306933 - C2: "assert(false) failed: infinite loop" failure
Description
There are currently a few places where we simply bail out of C2 compilation. Some of them are justified. Others just encounter a bug, but bail out gracefully. This means we never catch those bugs.

We should add an assert before record_method_not_compilable so that we can catch the bugs in debug build, but still handle it gracefully in production builds.

One example is JDK-8303466. I had a IR test for a SuperWord regression test, but it would not compile. Finally, I found that it bailed out of compilation:
   4163 85 b 4 Test::test (32 bytes) COMPILE SKIPPED: malformed control flow (retry at different tier)

But things like "malformed control flow" should be fixed. In this case, we have an IfNode that has only one output Projection.
Comments
The "malformed control flow" assert seems to trigger cases where skeleton/assertion predicates are missing.
05-04-2023
Changeset: af4d5600 Author: Emanuel Peter <epeter@openjdk.org> Date: 2023-03-23 07:44:18 +0000 URL: https://git.openjdk.org/jdk/commit/af4d5600e37ec6d331e62c5d37491ee97cad5311
23-03-2023
I did testing up to tier9. It looks like all asserts that I put in are now passing. We may have fuzzer failures for this JDK-8303466, that would be expected, but rare. If any of the asserts fail, we will have to re-evaluate if the assert is too strong, or if we indeed encounter a bug. Feel free to contact me if you are not sure.
23-03-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13038 Date: 2023-03-15 10:29:32 +0000
17-03-2023
I wonder if we should also check all the BAILOUT calls in C1?
13-03-2023
TestA.jasm After OSR bailout, we do not ever recompile the method. We could probably try a normal compilation, that would at least get us performance on the lest method call. I think this kind of pattern does get generated, not just in jasm. For example in Kitchensink: die.verwandlung.article2html::topLevel die.verwandlung.xmlspec::toc This is the PrintCompilation log: ... 870 27 % b 3 TestA::test @ 4 (15 bytes) compilation bailout: stack not empty at OSR entry point 871 27 % b 3 TestA::test @ 4 (15 bytes) COMPILE SKIPPED: stack not empty at OSR entry point (retry at different tier) 871 28 % b 4 TestA::test @ 4 (15 bytes) 872 28 % b 4 TestA::test @ 4 (15 bytes) COMPILE SKIPPED: OSR starts with non-empty stack (retry at different tier) 923 29 b 4 TestA::test (15 bytes) ./java -jar ~/Documents/asmtools-7.0-build/release/lib/asmtools.jar jasm TestA.jasm ./java -Xbatch -XX:CompileCommand=compileonly,TestA::test -XX:CompileCommand=printcompilation,TestA::test -XX:+PrintCompilation TestA
13-03-2023