JDK-8333393 : PhaseCFG::insert_anti_dependences can fail to raise LCAs and to add necessary anti-dependence edges
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,19,21,22,23,24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-06-02
  • Updated: 2025-04-29
  • Resolved: 2025-03-10
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 25
25 b14Fixed
Related Reports
Causes :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
# Failure analysis

When searching for load anti-dependences in GCM, the memory state for the load is sometimes represented not only by the memory node input of the load, but also other memory nodes. Because PhaseCFG::insert_anti_dependences searches for anti-dependences only from the load's memory input, it is, therefore, possible to sometimes overlook anti-dependences. The result is that loads are potentially scheduled too late, after stores that redefine the memory states of the loads.

Consider the attached ideal graph [1,2]. 64 membar_release is a critical anti-dependence. We search for anti-dependences from the load's direct memory input, 107 Phi. The search stops immediately at Phis, and thus ends at 106 Phi. This is not sufficient to find 64 membar_release.

Also, consider another example [3,4]. Here, the required anti-dependence is 75 Phi (or, rather, the last block on the path between 76 Phi and 75 Phi = B9). We search for anti-dependences from 18 MachProj, and therefore stop at 76 Phi and 77 Phi. This is not sufficient to raise the LCA as required.

[1] failure-graph-1.png
[2] failure-blocks-1.png
[3] failure-graph-2.png
[4] failure-blocks-2.png

# Original description

Nothing to go on, the problem seems to be the r11 test

----------System.err:(15/908)----------
java.lang.RuntimeException: assertEquals expected: 1 but was: 2
	at jdk.test.lib.Asserts.fail(Asserts.java:691)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:204)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:191)
	at applications.javafuzzer.JavaFuzzerRunner.reportResults(JavaFuzzerRunner.java:232)
	at applications.javafuzzer.JavaFuzzerRunner.runWithConfigurations(JavaFuzzerRunner.java:253)
	at applications.javafuzzer.JavaFuzzerRunner.main(JavaFuzzerRunner.java:275)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)


r11- 300: 186 passed, 0 crashes, 1 fails, 0 hangs, 0 incorrect tests, 113 Reference Java failures

Saving result: fails 288
    Failed!
Test r11-288 FAILED
r11-288 (239 lines) [177 passed, 0 crashes, 1 fails, 0 hangs, 0 incorrect tests, 110 Reference Java failures] - 96%/300
Comments
Changeset: b40be225 Branch: master Author: Daniel Lundén <dlunden@openjdk.org> Date: 2025-03-10 16:18:02 +0000 URL: https://git.openjdk.org/jdk/commit/b40be22512a8d3b3350fef8d6668d80134a6f1a6
10-03-2025

For future reference, the failures in this issue start to appear after integration of the changeset for JDK-8252372.
20-02-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23691 Date: 2025-02-19 09:52:41 +0000
19-02-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22852 Date: 2024-12-20 18:26:55 +0000
20-12-2024

Test.java no longer fails on mainline. Attaching a slightly modified version TestNew.java that does fail.
22-11-2024

I'm deferring this to JDK 25 for now. Feel free to still fix in JDK 24 if the fix is ready in time.
19-11-2024

The JavaFuzzer found another test that seems to trigger the same issue: java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test2::* -XX:-TieredCompilation -Xbatch -XX:+StressLCM -XX:+StressGCM Test2.java Needs a few iterations to reproduce: while java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test2::* -XX:-TieredCompilation -Xbatch -XX:+StressLCM -XX:+StressGCM Test2.java > stress.log && diff gold.log stress.log; do :; done
09-08-2024

ILW = Incorrect result with C2 compiled code, javafuzzer generated test with -XX:PerMethodTrapLimit=0, no workaround but disable compilation of affected method = HLM = P3
03-06-2024

I attached a reduced and hand-simplified test: java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test*::test -XX:-TieredCompilation -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:PerMethodTrapLimit=0 Test.java Exception in thread "main" java.lang.RuntimeException: Unexpected result: -2100 at Test.main(Test.java:26) It first reproduces after JDK-8287840 in JDK 19 but that seems to just trigger an existing issue.
03-06-2024