Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8131483

aarch64: illegal stlxr instructions

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None
    • Environment:

      armv8 XXXXXXX partner hardware

    • Subcomponent:
    • Resolved In Build:
      b76
    • CPU:
      aarch64
    • OS:
      linux

      Backports

        Description

        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 ---

          Activity

          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/aa7220a36fb0
          User: enevill
          Date: 2015-07-16 15:19:41 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/aa7220a36fb0 User: enevill Date: 2015-07-16 15:19:41 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/aa7220a36fb0
          User: lana
          Date: 2015-08-05 21:01:23 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/aa7220a36fb0 User: lana Date: 2015-08-05 21:01:23 +0000

            People

            • Assignee:
              enevill Ed Nevill
              Reporter:
              enevill Ed Nevill
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 1 day
                1d
                Logged:
                Time Spent - Not Specified
                Not Specified