Java Corretto 22 on EC2 ARM instance with Amazon Linux has crashed

[slavag]

Describe the bug

Java Corretto 22 on EC2 ARM instance with Amazon Linux has crashed

To Reproduce

Not sure I can provide steps to reproduce, please see attached Java crash log file

Platform information

OS: AArch64, 8 cores, 30G, Amazon Linux release 2 (Karoo)
Version: Corretto-22.0.1.8.1

java_error1641.log

[shipilev]

A few clues from the log:

The crash log says the JIT compiled code have crashed while trying to access 0xdeaddeaf000000c8:

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0xdeaddeaf000000c8

Current thread (0x0000ffff86093860):  JavaThread "SID:1175799067"        [_thread_in_Java, id=3446, stack(0x0000fffe25940000,0x0000fffe25b3e000) (2040K)]

Stack: [0x0000fffe25940000,0x0000fffe25b3e000],  sp=0x0000fffe25b3ae10,  free space=2027k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 90103 c2 java.lang.Object.toString()Ljava/lang/String; [email protected] (36 bytes) @ 0x0000ffff7610ea04 [0x0000ffff7610e940+0x00000000000000c4]
j  sun.security.ssl.SSLSocketInputRecord.decodeInputRecord()[Lsun/security/ssl/Plaintext;+185 [email protected]
J 11046 c2 sun.security.ssl.SSLTransport.decode(Lsun/security/ssl/TransportContext;[Ljava/nio/ByteBuffer;II[Ljava/nio/B

That address is interesting, and likely gives us a clue. Hotspot source code says has the magic deaddeaf for stack values read during the deopt, like:

  } else if (sv->is_constant_long()) {
    // Constant long in a single stack slot
    union { intptr_t p; jlong jl; } value;
    value.p = (intptr_t) CONST64(0xDEADDEAFDEADDEAF);
    value.jl = ((ConstantLongValue *)sv)->value();
    return new StackValue(value.p);

[shipilev]

Another clue in the log:

Event: 10898.333 Thread 0x0000ffff86095a40 Exception <a 'java/lang/IncompatibleClassChangeError'{0x00000007f46d1968}: Class Ljdk.internal.vm.FillerArray; does not implement the requested interface java.util.Map> (0x00000007f46d1968) 
thrown [src/hotspot/share/interpreter/interpreterRuntime.cpp, line 645]

This leads me to think at least part of might be an instance of a known regression in JDK 22: https://bugs.openjdk.org/browse/JDK-8329528. The fix is in 22.0.2, which would be released on 16 July 2024.

[shipilev]

More digging, disassembling Instructions: section:

        cmp     x11, x10                        // encoding: [0x7f,0x01,0x0a,0xeb]
        b.hs    #4864                           // encoding: [0x02,0x98,0x00,0x54]
        str     x11, [x28, #440]                // encoding: [0x8b,0xdf,0x00,0xf9]
        orr     x10, xzr, #0x1                  // encoding: [0xea,0x03,0x40,0xb2]
        prfm    pstl1keep, [x11, #192]          // encoding: [0x70,0x61,0x80,0xf9]
        str     x10, [x0]                       // encoding: [0x0a,0x00,0x00,0xf9]
        movz    x12, #0, lsl #16                // encoding: [0x0c,0x00,0xa0,0xd2]
        movk    x12, #8912                      // encoding: [0x0c,0x5a,0x84,0xf2]
        prfm    pstl1keep, [x11, #256]          // encoding: [0x70,0x81,0x80,0xf9]
        str     w12, [x0, #8]                   // encoding: [0x0c,0x08,0x00,0xb9]
        prfm    pstl1keep, [x11, #320]          // encoding: [0x70,0xa1,0x80,0xf9]
        str     w2, [x0, #12]                   // encoding: [0x02,0x0c,0x00,0xb9]
        add     x10, x0, #16                    // encoding: [0x0a,0x40,0x00,0x91]
                                        // =16
        stp     xzr, xzr, [x10]                 // encoding: [0x5f,0x7d,0x00,0xa9]
        dmb     ishst                           // encoding: [0xbf,0x3a,0x03,0xd5]
        mov     x21, x29                        // encoding: [0xf5,0x03,0x1d,0xaa]
        ldr     w11, [x21, #8]                  // encoding: [0xab,0x0a,0x40,0xb9]  <---- crash here
        eor     x22, x11, #0x3e000000000        // encoding: [0x76,0x11,0x5b,0xd2]
        mov     x10, x19                        // encoding: [0xea,0x03,0x13,0xaa]
        mov     x11, x0                         // encoding: [0xeb,0x03,0x00,0xaa]
        eor     x11, x11, x10                   // encoding: [0x6b,0x01,0x0a,0xca]
        lsr     x13, x0, #3                     // encoding: [0x0d,0xfc,0x43,0xd3]

x21 register + #8 matches si_addr:

R21=0xdeaddeaf000000c0
si_addr: 0xdeaddeaf000000c8