Open knn-k opened 3 years ago
I ran the test locally with OpenJDK11U-jdk_aarch64_linux_openj9_2021-02-01-15-59.tar.gz 15 times, but I could not reproduce the failure.
This could be a target-specific problem.
I ran the jit_hw_2 test three times with Grinder on test-packet-ubuntu1604-armv8-2, and they all passed. https://ci.adoptopenjdk.net/job/Grinder/6230/
The size of a compiled method was 1.2 MB (0x133504 bytes). It is larger than the range of AArch64 conditional branch. It failed to jump to a StackCheckFailure snippet.
start=0xffff80535050 end=0xffff80668554 jdk/internal/module/SystemModules$default::moduleDescriptors()[Ljav/lang/module/ModuleDescriptor;
(gdb) x/32i 0xffff80535050
0xffff80535050: ldr x0, [x20]
0xffff80535054: stur x30, [x20, #-8]
0xffff80535058: sub x20, x20, #0x3e0
0xffff8053505c: ldr x10, [x19, #80]
0xffff80535060: cmp x20, x10 --> Stack overflow check
0xffff80535064: b.ls 0xffff80468538 // b.plast --> Conditional branch to the PC address in the register dump
0xffff80535068: str x21, [x20, #80]
0xffff8053506c: str x22, [x20, #88]
0xffff80535070: str x23, [x20, #96]
JIT verbose log from a local run:
+ (warm) jdk/internal/module/SystemModules$default.moduleDescriptors()[Ljava/lang/module/ModuleDescriptor; @ 0000FFFF77AC0AC0-0000FFFF77BEAAEC OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=6 j9m=00000000000E7970 bcsz=19502 sync OSR GCR compThreadID=0 CpuLoad=100%(33%avg) JvmCpu=100%
The size of this method is 0x12A02C = 1,220,652 bytes. It is a huge method, and its last bytecode index is 19501.
This failure is not observed in builds 110-114 of https://ci.adoptopenjdk.net/view/Test_functional/job/Test_openjdk11_j9_extended.functional_aarch64_linux/ . It is not clear yet what makes the generated code so large.
Two failures (Illegal instruction) with cmdLineTester_decompilationTests in https://ci.adoptopenjdk.net/job/Test_openjdk11_j9_sanity.functional_aarch64_linux/120/ .
The workaround introduced by https://github.com/eclipse/omr/pull/5819 was replaced by https://github.com/eclipse/omr/pull/6171 .
jlink
generates the SystemModules$default
class dynamically, and the generated code is different every time from run to run. It is a known issue of jlink.
That makes this failure intermittent.
Failure link
https://ci.adoptopenjdk.net/view/Test_functional/job/Test_openjdk11_j9_extended.functional_aarch64_linux/107/tapResults/
You can find the same failure from 103 (on January 26) to 107 (on February 1), while 102 on January 20 was OK. Results before 102 is unavailable.
Optional info
Failure output (captured from console output)