Compilation Fails even from noOpt Level
connglli opened this issue · 7 comments
Java -version output
openjdk version "11.0.16-internal" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16-internal+0-adhoc..openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build master-4ca209b54, JRE 11 Linux amd64-64-Bit Compressed References 20220615_000000 (JIT enabled, AOT enabled)
OpenJ9 - 4ca209b54
OMR - 26b89f9f9
JCL - 231dcc9eeb based on jdk-11.0.16+6)
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)
Summary of problem
Looks like the test fails from noOpt level, so it should be different from #15306 and #15347. This affects both JDK11 and JDK8.
class Test {
int N = 256;
void mainTest(String[] strArr1) {
int i26, i28, i32;
byte[] byArr = new byte[N];
for (i26 = 12; i26 < 222; ++i26) {
for (i28 = 24; i28 > 1; i28 -= 3) for (i32 = 1; i32 < 4; i32 += 2) byArr[i28] -= i32;
for (int ax$14 = 3005; ax$14 < 6948; ax$14 += 1) {
boolean[] ax$11 = new boolean[576];
}
}
long ccc = checkSum(byArr);
System.out.println(ccc);
}
public static void main(String[] strArr) {
Test _instance = new Test();
_instance.mainTest(strArr);
}
public static long checkSum(byte[] a) {
long sum = 0;
for (int j = 0; j < a.length; j++) {
sum += (byte) (a[j] / (j + 1) + a[j] % (j + 1));
}
return sum;
}
}Results of OpenJ9:
$ ./OpenJ9/jdk11/java Test
0
Results of OpenJ9-Xint (HotSpot/ART also give the same result):
$ ./OpenJ9/jdk11/java -Xint Test
-114
Diagnosis
If you exclude Test.mainTest() from compilation, then it gives the same result as HotSpot/ART/OpenJ9-Xint
$ ./OpenJ9/jdk11/bin/java '-Xjit:exclude={Test.mainTest(*)*}' Test
-114
But if you compile Test.mainTest() even from noOpt level, it gives 0 again
$ ./OpenJ9/jdk11/bin/java '-Xjit:{Test.mainTest(*)*}(optlevel=noOpt)' Test
0
So I reckon this to be different from 15306 (scorching) and 15347 (hot). (So is JDK8.)
No problem reproducing this.
I will take a look at this
This is not a regression in 0.33. Reproducible on JDK8 back to at least 0.29.
This looks like a DTL issue. I duplicated the call to mainTest() a number of times. The result was zero only on the first iteration. Disabling DLT achieved the correct result in all cases.
Looks like the type information is not preserved for the DLT compile where byArr is stored.
byte[] byArr = new byte[N];
During IL-Gen all stores into byArr are assumed to be storing to a boolean array. BoolArrayStoreTransformer truncates the store to 1-bit with iand (n163n)
n87n bstorei <array-shadow>[#226 Shadow] [flags 0x80000601 0x0 ]
n86n aladd (internalPtr sharedMemory )
n64n ==>aload
n85n ladd
n84n i2l (X>=0 )
n65n ==>iload
n83n lconst 16
n164n i2b
n163n iand
n162n b2i
n79n i2b
n78n b2i
n77n i2b
n76n isub
n74n b2i
n73n bloadi <array-shadow>[#226 Shadow] [flags 0x80000601 0x0 ]
n72n aladd (internalPtr sharedMemory )
n64n ==>aload
n71n ladd
n70n i2l (X>=0 )
n65n ==>iload
n69n lconst 16
n75n iload <auto slot 4>[#392 Auto] [flags 0x3 0x0 ]
n161n iconst 1