With -XX:+UseCompressedOops, we write the contents of the heap region in the 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 CDS archives. During the JDK build, we specify -Xmx128m when dumping the default CDS archives. "heap_end" is usually at 0x100000000, so we will *usually* get the same address for "_requested_bottom".

However, on macOS 26, 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:
==========
When writing CDS archive with -XX:+UseCompressedOops, always align the top end of the heap region to 0x100000000. Also, force both the narrow base to 0 and narrow shift to 0.