JDK8 OpenJ9: Server and Desktop Gives Different Result

[connglli]

Java version

openjdk version "1.8.0_342-internal"
OpenJDK Runtime Environment (build 1.8.0_342-internal-_2022_06_10_15_18-b00)
Eclipse OpenJ9 VM (build master-3d06b2f9c, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20220610_000000 (JIT enabled, AOT enabled)
OpenJ9   - 3d06b2f9c
OMR      - cf8ddbd1a
JCL      - 2bb179375a based on jdk8u342-b05)

Javac version

javac 1.8.0_342-internal

Summary of problem

This issue gives a quite tricky Test.java.

On one hand, OpenJ9 (with above version) produces different result from HotSpot and the Android Runtime (ART).

On the other hand, the results of OpenJ9 running on our desktop and server are also different; and both different from HotSpot/ART.

No matter desktop or server, the results of OpenJ9 are deterministic.

class Test {
  static long instanceCount;
  static long vMeth_check_sum;

  static void vMeth(double d, int i) {
    if (ax$0) {
      int ax$6;
      int ax$5;
      int ax$2 = 0x03;
      int ax$1 = 8080;
      int ax$4 = 70000;
      byte[] ax$3 = new byte[1 << 14];
      for (ax$5 = 1; ax$5 < 58; ax$5++)
        for (ax$6 = ax$5; 400 > ax$6; ax$6++) {
          ax$3[ax$6] -= ax$4;
          ax$1 += ax$6;
          switch (i % 5) {
            case 107:
              i >>= ax$2;
          }
        }
      return;
    }
    boolean bArr;
    int i21, i22 = 251, i25, i26 = 109, i27, i33 = 11;
    for (i25 = 8; 192 > i25; ++i25)
      for (i27 = 1; i27 < 3; ++i27) {
        instanceCount += i22;
        i33 = 1;
        i26 += i33;
      }
    vMeth_check_sum += i26 + i33;
  }

  void mainTest(String[] strArr1) {
    try {
      ax$0 = true;
      for (int ax$9 = 0; ax$9 < 6683; ax$9 += 1) vMeth(0.2660549401640039, 572329205);
    } finally {
      ax$0 = false;
    }
    vMeth(2.39889, 4);
    System.out.println(vMeth_check_sum);
  }

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

  static Boolean ax$0;
}

Results of OpenJ9 on our desktop:

478
772
1066
1360
1654
1948
2242
2536
2830

Results of OpenJ9 on our server:

294
588
882
1176
1470
1764
2058
2352
2646
2940

Results of OpenJ9 (Interpreter), HotSpot (JDK8/11/17) and the Android Runtime (ART):

478
956
1434
1912
2390
2868
3346
3824
4302
4780

Configuration

Our desktop (Ubuntu 20.04; Intel i7; 16GiB )

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS"

$ cat /proc/cpuinfo
...
vendor_id	: GenuineIntel
cpu family	: 6
model		: 158
model name	: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
...

Our server (Ubuntu 20.04; AMD Threadripper; 256GiB )

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS"

$ cat /proc/cpuinfo
...
vendor_id	: AuthenticAMD
cpu family	: 23
model		: 49
model name	: AMD Ryzen Threadripper 3990X 64-Core Processor
...

[connglli]

If you need any further information, please let me know.

[pshipton]

This one doesn't duplicate for me.

[pshipton]

@0xdaryl fyi

[connglli]

I've tried to run it for much more times. Seems like this is not because of the underlying architecture (CPU, memory) and OS. This time my server occasionally gives me the same result as my desktop.

So maybe a duplicate of #15306? Not sure.

Try this unreduced one openj9-bug-75.tar.gz.

[pshipton]

From 75 I get output like the following for a number of iterations, but all the output is the same as hotspot. Anyway, the JIT team may be able to find options that reproduce the problem when they get a chance to look.

i34 i35 i36 = 141,1590768,1
i37 d5 i38 = 1590953,-4603804719079489536,4
i39 i40 i41 = 116469659,1,-878073235
l i42 i43 = 3643512466,2,0
f1 i44 i45 = 1065353216,22488,2
l1 b4 byArr = 0,1,2722
Test.instanceCount Test.byFld Test.fFld = -4178497699,-77,-8388608
Test.iFld Test.lFld sFld = 889670,-6917529027641081856,1
Test.lFld1 Test.iArrFld Test.lArrFld = 264,-15120450,2085677664604679761
Test.fArrFld dArrFld = -4467221900870020433,-4466717620183270801
dMeth_check_sum: 2166490774697893434
vMeth1_check_sum: -9142143407265265581
vMeth_check_sum: -9222328261576422888

[0xdaryl]

The test fails when Test.vMeth(DI)V is compiled at scorching and passes with -Xjit:disableSequenceSimplification.

This is very likely a duplicate of #15306, but I can't yet rule out there are two different defects in expressions simplification.

[0xdaryl]

This is not a 0.33 regression. It fails at least as far back as 0.24 with JDK11.

[0xdaryl]

The investigation won't be complete for 0.33 and any fix wouldn't have time to soak in the head stream anyway. This is not a regression, so moving this out to 0.34.

[hzongaro]

I think the prototype fix I have for issue #15534 will fix this issue as well. As I mentioned there, I'm worried about the potential impact on performance and correctness, and so I would rather not rush in the fix. Peter @pshipton, may I ask you to move this one out of the 0.35 release.

[hzongaro]

I believe this issue is a duplicate of issue #15306, but I'm having troubling reproducing the failure again. I used to be able to reproduce it.

Update: I am now able to reproduce this failure again, and I have confirmed that it is a duplicate of #15306

[hzongaro]

Duplicate of #15306

[connglli]

@hzongaro Could you tell me which test case (the original one or the one commented in 27 July) this one is duplicate to?

[hzongaro]

Could you tell me which test case (#15306 (comment) or #15306 (comment)) this one is duplicate to?

@connglli It was the original one that this duplicates. Sorry for not being clear!

[connglli]

Well done @hzongaro. You're always having a great work!!!

[hzongaro]

Fixed by OMR pull request eclipse/omr#6747