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

aarch64: KlassDecodeMovk mode broken

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 17
    • Fix Version/s: 17
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b23
    • CPU:
      aarch64

      Description

      While adding support for ZGC on macOS/aarch64 ran into a test failure with runtime/cds/SharedBaseAddress.java. It looks like the compressed class pointer mode KlassDecodeMovk is broken and
      provokes the following guarantee in src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp when using ZGC.

      [...]
      [0.081s][info ][gc,metaspace] CDS archive(s) mapped at: [0x0000000500000000-0x0000000500c00000-0x0000000500c00000), size 12582912, SharedBaseAddress: 0x0000000500000000, ArchiveRelocationMode: 0.
      [0.081s][info ][gc,metaspace] Compressed class space mapped at: 0x0000000500c00000-0x0000000540c00000, reserved size: 1073741824
      [0.081s][info ][gc,metaspace] Narrow klass base: 0x0000000500000000, Narrow klass shift: 3, Narrow klass range: 0x100000000
      [...]
      # To suppress the following error report, specify this argument
      # after -XX: or in .hotspotrc: SuppressErrorAt=/macroAssembler_aarch64.cpp:4026
      #
      # A fatal error has been detected by the Java Runtime Environment:
      #
      # Internal Error (/Users/pliden/jdk/open/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4026), pid=57121, tid=6403
      # guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: compressed class base bad alignment


      When using non-ZGC collectors, the "Narrow klass base" is typically 0x0000000400000000 and MacroAssembler::klass_decode_mode() returns KlassDecodeXor. However, ZGC just happens to reserve slightly more memory at startup, so the "Narrow klass base" gets pushed up to 0x0000000500000000 and MacroAssembler::klass_decode_mode() then crashes.

      This problem can be provoked with any GC by just reserving some memory during startup. For example, you will see the same crash with G1 if you insert the following code somewhere in CollectedHeap::CollectedHeap():

        os::reserve_memory(0x200000000, !ExecMem, mtGC);

      and then run the test runtime/cds/SharedBaseAddress.java on macOS/aarch64.

      This looks like a generic aarch64 issue, and not directly related to macOS. But the compressed class base might end up at a different address on other OS:es, so that might have hidden the problem.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              stuefe Thomas Stuefe
              Reporter:
              pliden Per Liden
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: