JDK-8288975 : Incorrect result with C2 compiled code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11.0.15
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2022-06-21
  • Updated: 2025-02-12
  • Resolved: 2022-08-17
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 11
11-poolResolved
Related Reports
Duplicate :  
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :

Arch: x86_64
OS: Ubuntu 20.04.4 LTS
HotSpot
- openjdk version "11.0.17-internal" 2022-10-18
- OpenJDK Runtime Environment (fastdebug build 11.0.17-internal+0-adhoc.congli.my-jdk11u)
- OpenJDK 64-Bit Server VM (fastdebug build 11.0.17-internal+0-adhoc.congli.my-jdk11u, mixed mode)
javac: javac 11.0.17-internal

A DESCRIPTION OF THE PROBLEM :
The problem was found in the repo https://github.com/openjdk/jdk11u-dev (commit f915a327), OpenJDK 11.0.17 (internal). 

HotSpot's JIT and INT gives different result:

```
$ ./jdk11u/bin/java -Xint Test
-66
125
61
-4
-70
122
57
-8
-73
118

$ ./jdk11u/bin/java -Xbatch Test
-66
5
-59
-125
66
2
-63
127
63
-1
```


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. javac Test.java
2. java -Xint Test
3. java -Xbatch Test
4. observe the output of Step 2 and Step 3

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
-66
125
61
-4
-70
122
57
-8
-73
118
ACTUAL -
-66
5
-59
-125
66
2
-63
127
63
-1

---------- BEGIN SOURCE ----------
class Test {
  final int N = 256;
  byte byFld;
  float fFld;
  int iFld;
  int[] iArrFld;

  void vMeth1() {
    int i6 = 199, iArr[] = new int[N];
    float f2 = 45.363F;
    init(iArr, 5);
    iArrFld = iArr;
    for (int i5 : iArr) {
      try {
        i5 = 12430 / iArrFld[(i5 >>> 1) % N];
        iArrFld[(i5 >>> 1) % N] = 141 / i5;
        i5 = i5 / i5;
      } catch (ArithmeticException a_e) {
      }
      switch ((i5 >>> 1) % 10 + 36) {
        case 36:
          java.io.PrintStream ax$2 =
              new java.io.PrintStream(
                  new java.io.OutputStream() {
                    public void write(int b) {}
                  });
          for (int ax$8 = -2967; ax$8 < 4342; ax$8 += 4) {}
          byFld += f2;
        case 40:
          break;
        case 41:
          iArr[1] -= i6;
      }
    }
  }

  void vMeth() {
    if (ax$18) return;
    vMeth1();
  }

  float fMeth(float f, int i, short s) {
    int i1;
    short[] sArr = new short[N];
    for (i1 = 2; i1 < 215; ++i1) {
      try {
        ax$18 = true;
        for (int ax$25 = 0; ax$25 < 9676; ax$25 += 1) vMeth();
      } finally {
        ax$18 = false;
      }
      vMeth();
    }
    long meth_res = checkSum(sArr);
    return meth_res;
  }

  void mainTest(String[] strArr1) {
    short s2 = 10116;
    fMeth(fFld, iFld, s2);
    System.out.println(byFld);
  }

  public static void main(String[] strArr) {
    Test _instance = new Test();
    for (int i = 0; i < 10; i++) _instance.mainTest(strArr);
  }

  public static long checkSum(short[] a) {
    long sum = 0;
    for (int j = 0; j < a.length; j++) {
      sum += (short) (a[j] / (j + 1) + a[j] % (j + 1));
    }
    return sum;
  }

  public static void init(int[] a, int seed) {
    for (int j = 0; j < a.length; j++) {
      a[j] = (j % 2 == 0) ? seed + j : seed - j;
    }
  }

  Boolean ax$18;
}
---------- END SOURCE ----------

FREQUENCY : always



Comments
I just double-checked that JDK-8258894 is an appropriate fix for this bug. The root of the failure (left CFG in before-and-after-JDK-8288975.png, see attachment) is a store node (247 storeI) that is placed in an inner loop (94 Loop in B8), because it has the same estimated frequency as the store's home loop (95 Loop in B7). However, the *actual* frequency of B8 is slightly higher than that of B7 (it is executed three more iterations), which leads to a higher final value of the 'result' field than expected (see JDK-8258894 for a more general description of the issue). Applying JDK-8258894, the store node is forced to be placed within its home loop (right CFG in before-and-after-JDK-8288975.png), which prevents the miscompilation.
26-08-2022

ILW = Incorrect execution of compiled code (old issue), single (generated) test, disable compilation of affected method or switch profiling = HLM = P3
19-07-2022

I attached a simplified version of the test (Test-1.java): java -Xbatch -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::vMeth* -XX:CompileCommand=dontinline,*::dontInline With that, I can reproduce the issue up to JDK 17. Both tests greatly depend on timing though. Several C1/C2 compilations need to happen in a certain sequence for the bug to manifest, probably because switch profiling (JDK-8200303) is involved. Although the tests do not reproduce the issue with latest JDK 20, I'm pretty sure it is affected as well.
19-07-2022

This starts failing with JDK-8234147 in JDK 11.0.10 but this change probably just triggers a certain code path.
19-07-2022

Issue is reproduced. -Xint and -Xbatch give different results in JDK 11.0.15.1, all other JDK versions give same result. OS: Windows 10 JDK 8u333: Pass JDK 11.0.15.1: Fail JDK 17.0.3.1: Pass JDK 18.0.1.1: Pass Failed Output: java -Xint Test -66 125 61 -4 -70 122 57 -8 -73 118 >java -Xbatch Test -66 5 -59 -125 66 2 -63 127 63 -1 Moving it to dev team for further analysis.
22-06-2022