hzongaro
commented
10 months ago Taking a quick look at the jitdump file, it looks like there's a problem with the child of a ResolveCHK node. The IL dump breaks off at that point in the IL for the original compilation and for the jitdump recompilation:
n51n NULLCHK on n46n [#32] [0x7fd18a004a30] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=1
n50n PassThrough [0x7fd18a0049e0] bci=[-1,35,-] rc=1 vc=0 vn=- li=- udi=- nc=1
n46n aload cp<parm 2 Lsun/security/util/ConstraintsParameters;>[#423 Parm] [flags 0x40000107 0x0 ] [0x7fd18a0048a0] bci=[-1,32,-] rc=5 vc=0 vn=- li=- udi=- nc=0
n57n ZEROCHK [#54] [0x7fd18a090190] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=1
n55n iload <temp slot 15>[#475 Auto] [flags 0x3 0x0 ] [0x7fd18a0900f0] bci=[-1,35,-] rc=2 vc=0 vn=- li=- udi=- nc=0
n231n istore <temp slot 12>[#472 Auto] [flags 0x3 0x0 ] [0x7fd18a0937f0] bci=[-1,0,-] rc=0 vc=0 vn=- li=- udi=- nc=1
n55n ==>iload
n49n treetop [0x7fd18a004990] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=1
n48n acalli java/lang/Object.toString()Ljava/lang/String;[#435 virtual Method -56] [flags 0x500 0x0 ] [0x7fd18a004940] bci=[-1,35,-] rc=2 vc=0 vn=- li=- udi=- nc=2
n47n aloadi <vft-symbol>[#346 Shadow] [flags 0x18607 0x0 ] [0x7fd18a0048f0] bci=[-1,35,-] rc=1 vc=0 vn=- li=- udi=- nc=1
n46n ==>aload
n46n ==>aload
n230n astore <temp slot 11>[#471 Auto] [flags 0x7 0x0 ] [0x7fd18a0937a0] bci=[-1,0,-] rc=0 vc=0 vn=- li=- udi=- nc=1
n48n ==>acalli
n227n treetop [0x7fd18a0936b0] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=1
n46n ==>aload
n244n ifacmpeq --> block_27 BBStart at n241n () [0x7fd18a093c00] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=2 flg=0x20
n46n ==>aload
n243n aconst NULL (X==0 X>=0 X<=0 ) [0x7fd18a093bb0] bci=[-1,35,-] rc=1 vc=0 vn=- li=- udi=- nc=0 flg=0x302
n229n BBEnd </block_3> ===== [0x7fd18a093750] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=0
n228n BBStart <block_25> [0x7fd18a093700] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=0
n251n ResolveCHK [#351] [0x7fd18a093e30] bci=[-1,35,-] rc=0 vc=0 vn=- li=- udi=- nc=1
</recompilation rc=0 queued=1>
</jitDump>
avermeer
pshipton
dsouzai
a7ehuo
Java -version output
openjdk version "21.0.1" 2023-10-17 LTS IBM Semeru Runtime Open Edition 21.0.2.0-m2 (build 21.0.1+12-LTS) Eclipse OpenJ9 VM 21.0.2.0-m2 (build v0.43.0-release-54becab46, JRE 21 Linux amd64-64-Bit Compressed References 20231017_57 (JIT enabled, AOT enabled) OpenJ9 - 54becab46 OMR - d810fcb98 JCL - 10a4ed68a77 based on jdk-21.0.1+12)
Summary of problem
We have a GPF crash in our preproduction web application (using on top of TomEE 9.1.2 on Redhat Linux 8.7 on Linux x64) with Semeru Runtime Open Edition 21.0.2.0-m2. While we don't know the exact scenario to reproduce, the GPF crash took place on the two different VMs running our web application last night, and the night before, with same type of dumps.
The issue seems to take place when JIT compiler is trying compile sun/security/util/DisabledAlgorithmConstraints$Constraints.permits, given this output which we found in catalina.out:
Please note that since IBM Semeru 21.0.1 has been officially released, I am going to switch to this version - I will let you know if the GPF issue takes place on it too (but once I'll have moved to 21.0.1 official, I may not be able to switch back easily to 21.0.2-m2 if you need more details to find the root cause & fix it).
Diagnostic files
See attached .dmp file (.core file was nowhere...)
jitdump.20240111.224658.381973.0004.dmp
See attached .trc file (ZIPped):
Snap.20240111.224658.381973.0003.trc.zip
vmState [0x53cff]: {J9VMSTATE_JIT} {coldBlockMarker}