RFR: 8309065: Move the logic to determine archive heap location from CDS to G1 GC [v3]

[Thomas Stuefe]

On Wed, 7 Jun 2023 14:23:20 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 551:
>> 
>>> 549:   HeapWord* start_addr = reserved.end() - align_up(word_size, HeapRegion::GrainWords);
>>> 550:   MemRegion range = MemRegion(start_addr, word_size);
>>> 551:   HeapWord* last_address = range.last();
>> 
>> Do I understand this - and the old code - correctly: we map the archive region at the end of the heap, therefore, if heap size changed between dump time and runtime, we will always have to relocate? I didn't look but I assume the dumptime heap size is the default heap size?
>> 
>> Another, possibly stupid, question: why don't we use the Heap bottom - we'd still avoid fragmentation but have a much higher chance of not relocating?
>
>> we map the archive region at the end of the heap, therefore, if heap size changed between dump time and runtime, we will always have to relocate
> 
> Not always. For small heap sizes under 2G with compressedoops the heap is mapped such that top of the heap is at 4G boundary. So by keeping the archive regions towards the end, we can get same offset even if the heap size changes. If we map towards the bottom, then the offsets would change as the heap size changes.
> 
> For example, the default archive is created with 128m. So executing:
> 
> $ java -Xlog:cds -Xmx128m -version
> [0.003s][info][cds] The current max heap size = 128M, HeapRegion::GrainBytes = 1048576
> [0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
> [0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
> [0.003s][info][cds]     heap range = [0x00000000f8000000 - 0x0000000100000000]
> [0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
> [0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
> [0.003s][info][cds] CDS heap data relocation delta = 0 bytes
> 
> 
> Changing the heap size to 256m:
> 
> $ java -Xlog:cds -Xmx256m -version
> [0.003s][info][cds] The current max heap size = 256M, HeapRegion::GrainBytes = 1048576
> [0.003s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
> [0.003s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
> [0.003s][info][cds]     heap range = [0x00000000f0000000 - 0x0000000100000000]
> [0.003s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000
> [0.003s][info][cds] Heap data mapped at 0x00000000ffe00000, size =  1071752 bytes
> [0.003s][info][cds] CDS heap data relocation delta = 0 bytes
> 
> 
> Notice that relocation delta is 0 in both cases and the heap data is mapped at same address.

@ashu-mehra Ah, thank you. I remembered this wrongly as the heap having a preferred fixed start address when the fix point was actually the end of the zero-based encoding range.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14208#discussion_r1221704559