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

Heap region in AOT cache is not at deterministic address

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: P3 P3
    • 26
    • 26
    • hotspot
    • macOS 26 Beta 4 running in a VM over UTM using 6 GiB RAM, 96 GiB HDD, and 4 cores. Base os is macOS 15.5 MacBook Pro M3 with 36 GiB RAM

    • aarch64
    • os_x

      With -XX:+UseCompressedOops, we write the contents of the heap region in the AOT cache (aka CDS archive) with the assumption that the heap region will be loaded at this address in the production run:

          ArchivedHeapWriter::_requested_bottom

      which is calculated here:

      https://github.com/openjdk/jdk/blob/ad510fb25e47098d136515c355164e5177c5b419/src/hotspot/share/cds/archiveHeapWriter.cpp#L479

        if (UseCompressedOops) {
          if (UseG1GC) {
            address heap_end = (address)G1CollectedHeap::heap()->reserved().end();
            log_info(aot, heap)("Heap end = %p", heap_end);
            _requested_bottom = align_down(heap_end - heap_region_byte_size, G1HeapRegion::GrainBytes);
            _requested_bottom = align_down(_requested_bottom, MIN_GC_REGION_ALIGNMENT);
            assert(is_aligned(_requested_bottom, G1HeapRegion::GrainBytes), "sanity");
          } else {
            _requested_bottom = align_up(CompressedOops::begin(), MIN_GC_REGION_ALIGNMENT);
          }

      By default, G1 is used when creating AOT caches, and on our platforms, "heap_end" is usually at 0x800000000, so we will *usually* get the same address for "_requested_bottom".

      However, on macOS 26 Beta 4, we have seen that this assumption no longer holds true. It's probably because macOS is using more aggressive ASLR. In an failed instance of runtime/cds/DeterministicDump.java, we have

      SharedArchiveFile3.map:
      [heap 0x000000047fe00000 - 0x000000047ff20160 1180000 bytes]

      SharedArchiveFile5.map:
      [heap 0x000000011b600000 - 0x000000011b720160 1180000 bytes]


      Proposed fix:
      ==========
      With -XX:+UseCompressedOops, before writing the heap region into the CDS archive, relocate every oop pointer so that the loading address is always at 0x10000000.

      (Note: it's already the case that with UseCompressedOops=false, the loading address is fixed at 0x10000000, so the proposed fix will make the behavior more consistent).

      PROS: Heap region image will now always be deterministic
      CONS: Heap region always needs relocation, so there's an extra runtime cost. But this is very small compared to the rest of start-up.

            iklam Ioi Lam
            iklam Ioi Lam
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: