Bug ID: JDK-8356708 C2: loop strip mining expansion doesn't take sunk stores into account

Versions (Unresolved/Resolved/Fixed)

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	JDK 26
25Fixed	26 b04Fixed

Attached Test.java fails when C2 compiled.

    static void test() {
        for (int i = 1500; i > 0; i--) {
            try {
                int tmp = array[idx--];
            } catch (Exception e) {
                // Ignore
            }
        }
    }

java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*Test*::test -XX:-TieredCompilation -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM Test.java
Exception in thread "main" java.lang.RuntimeException: Wrong result: -2500 != -1500
at Test.main(Test.java:43)

A pull request was submitted for review. Branch: jdk25 URL: https://git.openjdk.org/jdk/pull/25929 Date: 2025-06-23 07:19:27 +0000
23-06-2025
Changeset: c11f36e6 Branch: master Author: Roland Westrelin <roland@openjdk.org> Date: 2025-06-20 11:24:17 +0000 URL: https://git.openjdk.org/jdk/commit/c11f36e6200b6c39fd59530f28e9318c4153db49
20-06-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25717 Date: 2025-06-10 10:17:11 +0000
10-06-2025
> [~thartmann] I guess the priority stays at P2 even though there is a less radical workaround available? Yes, I think a P2 is still justified.
02-06-2025
[~roland] I had a quick look and it seems the changes to the strip-mined loop adjustment logic in JDK-8281322 break the memory graph for this case (the store corresponding to idx-- gets its memory state from the starting state rather than from a memory phi at the outer loop header), which I guess ends up causing the miscompilation. Could you have a look?
28-05-2025
Late barrier expansion for G1 is not the root cause of this failure, it just made it surface by 1) enabling optimizations involved in the failure that were blocked for G1 with early barrier expansion, due to explicit GC barrier nodes, and 2) causing a different unrolling decision, due to slight cost model differences. The failure can be traced back to at least JDK-8281322 by running the reproducer with the following JVM configuration: $ java -Xbatch -XX:+UseZGC -XX:LoopMaxUnroll=1 Test.java A workaround is to use -XX:-SplitIfBlocks. [~thartmann] I guess the priority stays at P2 even though there is a less radical workaround available?
28-05-2025
ILW = Wrong execution of C2 compiled code, fuzzer generated test case but easy to reproduce, no workaround but disable compilation of affected method or use different GC = HMM = P2
13-05-2025
I attached a reduced Test: java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::test -XX:-TieredCompilation -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM Test.java Exception in thread "main" java.lang.RuntimeException: Wrong result: -2500 != -1500 at Test.main(Test.java:43)
13-05-2025
Reproducible (intermittent) with: java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::* -XX:-TieredCompilation -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM Test_4368.java
12-05-2025
Only reproduces since JDK-8334060 in JDK 24 b18 and only seems to reproduce with G1 GC.
12-05-2025

Causes :	JDK-8281322 - C2: always construct strip mined loop initially (even if strip mining is disabled)
Relates :	JDK-8360096 - C2/loop strip mining: investigate fully built outer loop from construction
Relates :	JDK-8359440 - C2: improve IR test coverage of basic loop optimizations