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.
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.
- is blocked by
-
JDK-8362566 Use -Xlog:aot+map to print contents of existing AOT cache
-
- Open
-