One of our partners reports that jdk9 is generating illegal stlxr instructions.

--- CUT HERE ---
Think I found a bug in the OpenJDK8/9 that’s generating an undefined instruction that works for some platforms, but not others.

 

I’ve been running SPECjbb2015 on QEMU, and that seems to work fine. However, when I moved to the armv8 XXXXX platform, all of my SPECjbb2015 runs (on both OpenJDK8 as well as the OpenJDK9 from Linaro and my own locally-built OpenJDK9) crashed on the following instruction:

 

STLXR W8, X10, [X8] ;; the register in the middle varies, but the important part is that the status result register

                    ;; and the base register are the same)

 

At first, I thought this was an issue with XXXXXX, but digging into the ARM ARM (which lists the instruction as “STLXR Ws, Xt, [Xn]”), it specifies that if this is a store, and (s == n) && (n != 31), then this is a Constrained Unpredictable instruction. From page 5447 of the ARM ARM (latest version):

 

If s == n && n != 31 then one of the following behaviors can occur:

• The instruction is UNDEFINED.

• The instruction executes as a NOP.

• The instruction performs the store to an UNKNOWN address.

 

The XXXXXX treat this as the first bullet point – it gets flagged as an UNDEFINED instruction, which triggers the SIGILL signal and ends the process. I’m assuming that the YYYYYY and QEMU are treating this either as the second or third bullet point, which would let them continue execution, but without seeing the crash as I do on XXXXXXX.

 

I generated a native-code implementation of a similar instruction sequence, which works on QEMU and on the YYYYYYY hardware, but causes a SIGILL on the XXXXXX as well.
--- CUT HERE ---