The mis-compilation phenomenon occurring at LastOptIndex 102 under JIT Hot Level

[Qeryu]

Java -version output

openjdk version "1.8.0_412-internal"
OpenJDK Runtime Environment (build 1.8.0_412-internal-xiezf_2024_03_06_10_45-b00)
Eclipse OpenJ9 VM (build master-8c1d42dad, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20240306_000000 (JIT enabled, AOT enabled)
OpenJ9   - 8c1d42dad
OMR      - 8bea58e95
JCL      - 16aa7c2499 based on jdk8u412-b05)

Summary of problem

When running the following testcase with openj9-openjdk-jdk8, there is an incorrect output result.

class Test {

  int a = 256;
  long g;
  volatile float b;
  long m;

  void c() {
    int h = 9;
    long[] j = new long[a];
    for (int k = 8; k < 98; ++k) h += g;
    m = h;
    for (int i = 0; i < a; i++) {
      m += j[i];
    }
  }

  void l() {
    for (int i = 4; 175 > i; ++i) for (int d = 8; d < 173; ++d) {
      g = (long) (5 - g + b);
      c();
    }
    System.out.println(m);
  }

  public static void main(String[] e) {
    Test f = new Test();
    for (int i = 0; i < 10; i++) f.l();
  }
}

The correct result should be

459
9
459
9
459
9
459
9
459
9

But when running in openj9-openjdk-jdk8, the result given by the program is

459
9
459
459
9
459
9
459
9
459

I further pinpointed the potential issue to LastOptIndex and used '-Xjit:{Test.l(*)*}(optLevel=hot,lastOptIndex=102,optDetails,log=jit.log)'. At LastOptIndex 102, the exception can be triggered stably, while at LastOptIndex 101, the exception disappears. The optimization corresponding to LastOptIndex is partialRedundancyElimination, which is similar to Issue #18777, but it is not the same LastOptIndex.

jit.log.478608.14881.20240306.164801.478608.log

[pshipton]

@hzongaro fyi

[hzongaro]

I took a quick look at this failure, and I believe it's a duplicate of issue #18777. @a7ehuo, may I ask you to confirm that?

[a7ehuo]

the optimization corresponding to LastOptIndex is partialRedundancyElimination, which is similar to https://github.com/eclipse-openj9/openj9/issues/18777, but it is not the same LastOptIndex.

Different method compiled at different optLevel can have different optimization index.

I'm not able to reproduce this issue locally but I took a look at jit.log.478608.14881.20240306.164801.478608.log. After deadTreeElimination, the volatile load of the field Test.b n42n is buried under a store node: lstorei n47n. This looks the same issue as #18777: there are two side effects under one treetop, which could potentially cause confusion/incorrectness in other passes of the optimizations.

n32n      BBStart <block_6> (freq 5534)                                                       [0x7effd4dbe2d0] bci=[-1,19,20] rc=0 vc=115 vn=- li=-1 udi=- nc=0
n43n      treetop                                                                             [0x7effd4dbe640] bci=[-1,30,20] rc=0 vc=115 vn=- li=-1 udi=- nc=1
n40n        l2f                                                                               [0x7effd4dbe550] bci=[-1,28,20] rc=2 vc=116 vn=- li=- udi=- nc=1
n39n          lsub                                                                            [0x7effd4dbe500] bci=[-1,27,20] rc=1 vc=116 vn=- li=- udi=- nc=2
n36n            lconst 5 (highWordZero X!=0 X>=0 )                                            [0x7effd4dbe410] bci=[-1,20,20] rc=1 vc=116 vn=- li=- udi=- nc=0 flg=0x4104
n38n            lloadi  Test.g J[#428  Shadow +8] [flags 0x604 0x0 ] (cannotOverflow )        [0x7effd4dbe4b0] bci=[-1,24,20] rc=1 vc=116 vn=- li=- udi=- nc=1 flg=0x1000
n37n              aload  <'this' parm LTest;>[#422  Parm] [flags 0x40000107 0x0 ] (X!=0 X>=0 )  [0x7effd4dbe460] bci=[-1,23,20] rc=1 vc=116 vn=- li=- udi=- nc=0 flg=0x104
n44n      treetop                                                                             [0x7effd4dbe690] bci=[-1,30,20] rc=0 vc=117 vn=- li=-1 udi=- nc=1
n42n        floadi  Test.b F[#429  volatile Shadow +28] [flags 0x2605 0x0 ]                   [0x7effd4dbe5f0] bci=[-1,30,20] rc=2 vc=117 vn=- li=- udi=- nc=1
n41n          aload  <'this' parm LTest;>[#422  Parm] [flags 0x40000107 0x0 ] (X!=0 X>=0 )    [0x7effd4dbe5a0] bci=[-1,29,20] rc=1 vc=116 vn=- li=- udi=- nc=0 flg=0x104
n304n     treetop                                                                             [0x7effd4e3dec0] bci=[-1,33,20] rc=0 vc=0 vn=- li=- udi=- nc=1
n45n        fadd                                                                              [0x7effd4dbe6e0] bci=[-1,33,20] rc=2 vc=116 vn=- li=1 udi=- nc=2
n40n          ==>l2f
n42n          ==>floadi
n47n      lstorei  Test.g J[#428  Shadow +8] [flags 0x604 0x0 ]                               [0x7effd4dbe780] bci=[-1,35,20] rc=0 vc=115 vn=- li=-1 udi=- nc=2
n35n        aload  <'this' parm LTest;>[#422  Parm] [flags 0x40000107 0x0 ] (X!=0 X>=0 )      [0x7effd4dbe3c0] bci=[-1,19,20] rc=1 vc=115 vn=- li=- udi=- nc=0 flg=0x104
n46n        f2l                                                                               [0x7effd4dbe730] bci=[-1,34,20] rc=1 vc=115 vn=- li=- udi=- nc=1
n45n          ==>fadd
...
...
<optimization id=34 name=deadTreesElimination method=Test.l()V>
Performing 34: deadTreesElimination
         O^O DEAD TREES ELIMINATION: it is safe to remove volatile field load tree n42n
...
...
n32n      BBStart <block_6> (freq 5534)                                                       [0x7effd4dbe2d0] bci=[-1,19,20] rc=0 vc=200 vn=- li=-1 udi=- nc=0
n43n      treetop                                                                             [0x7effd4dbe640] bci=[-1,30,20] rc=0 vc=200 vn=- li=-1 udi=- nc=1
n40n        l2f                                                                               [0x7effd4dbe550] bci=[-1,28,20] rc=2 vc=200 vn=- li=- udi=- nc=1
n39n          lsub                                                                            [0x7effd4dbe500] bci=[-1,27,20] rc=1 vc=200 vn=- li=- udi=- nc=2
n36n            lconst 5 (highWordZero X!=0 X>=0 )                                            [0x7effd4dbe410] bci=[-1,20,20] rc=1 vc=200 vn=- li=- udi=- nc=0 flg=0x4104
n38n            lloadi  Test.g J[#428  Shadow +8] [flags 0x604 0x0 ] (cannotOverflow )        [0x7effd4dbe4b0] bci=[-1,24,20] rc=1 vc=200 vn=- li=- udi=- nc=1 flg=0x1000
n37n              aload  <'this' parm LTest;>[#422  Parm] [flags 0x40000107 0x0 ] (X!=0 X>=0 )  [0x7effd4dbe460] bci=[-1,23,20] rc=1 vc=200 vn=- li=- udi=- nc=0 flg=0x104
n47n      lstorei  Test.g J[#428  Shadow +8] [flags 0x604 0x0 ]                               [0x7effd4dbe780] bci=[-1,35,20] rc=0 vc=200 vn=- li=-1 udi=- nc=2
n35n        aload  <'this' parm LTest;>[#422  Parm] [flags 0x40000107 0x0 ] (X!=0 X>=0 )      [0x7effd4dbe3c0] bci=[-1,19,20] rc=1 vc=200 vn=- li=- udi=- nc=0 flg=0x104
n46n        f2l                                                                               [0x7effd4dbe730] bci=[-1,34,20] rc=1 vc=200 vn=- li=- udi=- nc=1
n45n          fadd                                                                            [0x7effd4dbe6e0] bci=[-1,33,20] rc=1 vc=200 vn=- li=- udi=- nc=2
n40n            ==>l2f
n42n            floadi  Test.b F[#429  volatile Shadow +28] [flags 0x2605 0x0 ]               [0x7effd4dbe5f0] bci=[-1,30,20] rc=1 vc=200 vn=- li=- udi=- nc=1
n41n              aload  <'this' parm LTest;>[#422  Parm] [flags 0x40000107 0x0 ] (X!=0 X>=0 )  [0x7effd4dbe5a0] bci=[-1,29,20] rc=1 vc=200 vn=- li=- udi=- nc=0 flg=0x104

[hzongaro]

@a7ehuo, do you believe this problem was fixed by OMR pull request eclipse/omr#7281?

[a7ehuo]

do you believe this problem was fixed by OMR pull request https://github.com/eclipse/omr/pull/7281?

I still can't reproduce it. Based on my previous analysis of the log, it looks the same issue as https://github.com/eclipse-openj9/openj9/issues/18777 which should be fixed by https://github.com/eclipse/omr/pull/7281

[hzongaro]

@Qeryu, are you still able to reproduce this failure with @a7ehuo's fix from OMR pull request eclipse/omr#7281? If not, I think it's likely that that fixed the problem.

[a7ehuo]

I just tried the latest JDK8 and I think can I reproduce it as below. I'll take a look next, but I'm not too sure yet if it will meet 0.46 target depending on how complex the problem will be.

IBM Semeru Runtime Open Edition (build 1.8.0_412-b08)
Eclipse OpenJ9 VM (build openj9-0.44.0, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20240522_947 (JIT enabled, AOT enabled)
OpenJ9   - b0699311c7
OMR      - 254af5a04
JCL      - 3f438d726e based on jdk8u412-b08)

# jdk8u412-b08/bin/java '-Xjit:{Test.l(*)*}(optLevel=hot)' Test
459
9
459
9
9 // <-----
459
9
459
9
459

# jdk8u412-b08/bin/java -Xint Test
459
9
459
9
459
9
459
9
459
9

[hzongaro]

I just tried the latest JDK8 and I think can I reproduce it as below. I'll take a look next, but I'm not too sure yet if it will meet 0.46 target depending on how complex the problem will be.

Thanks for trying it out. I'll just move this out to the 0.48 release.

[a7ehuo]

@hzongaro sorry, my bad, please ignore my last comment about reproducing the issue. I realized I used v0.44 JDK8 release build which is old :disappointed:. The OMR 254af5a04 for v0.44 dated back to March. That explains why the issue happened.

Just to be sure, I rebuilt the JDK8 with the latest v0.46 branch. I tried both java '-Xjit:{Test.l(*)*}(optLevel=hot)' Test and java -Xjit:optLevel=hot Test. I do not repro the issue with the latest build from v0.46 branch.

@Qeryu, are you still reproducing the issue with the latest OMR/OpenJ9 code?

Eclipse OpenJ9 VM (build v0.46.0-release-5e0ca40ff8, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20240620_000000 (JIT enabled, AOT enabled)
OpenJ9   - 5e0ca40ff8
OMR      - 372b65ba1
JCL      - c1470c8cff based on jdk8u422-b03)

./openj9-openjdk-jdk8/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java '-Xjit:{Test.l(*)*}(optLevel=hot)' Test
459
9
459
9
459
9
459
9
459
9
./openj9-openjdk-jdk8/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -Xjit:optLevel=hot Test
459
9
459
9
459
9
459
9
459
9

[hzongaro]

I do not repro the issue with the latest build from v0.46 branch.

Thanks for the double-checking that, @a7ehuo. I'll go ahead and close this. @Qeryu, if you're still able to reproduce the problem, please reopen it.

[hzongaro]

Duplicates #18777