RFR: 8296344: Remove dependency on G1 for writing the CDS archive heap [v4]

[Ashutosh Mehra]

On Wed, 8 Feb 2023 03:20:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveHeapWriter.cpp line 388:
>> 
>>> 386:   assert(is_aligned(_open_bottom, HeapRegion::GrainBytes), "sanity");
>>> 387: 
>>> 388:   _requested_closed_region_bottom = align_down(heap_end - closed_region_byte_size, HeapRegion::GrainBytes);
>> 
>> Instead of aligning to `HeapRegion::GrainBytes`, shouldn't it be aligned to `MIN_GC_REGION_ALIGNMENT`?
>> With `HeapRegion::GrainBytes`, if the cds archive is created with large region size (say 32M) and later mapped with smaller region size (say 1M), then the archive heap would need to be relocated. Using `MIN_GC_REGION_ALIGNMENT` would avoid the relocation in this case.
>
> When we dump with a large heap size (e.g.,16GB) but with with a small heap size (e.g., 256M), we are likely to need to relocate anyway, because the narrowOop encoding would be different (3-bit shift vs no shift).
> 
> The design decision we made in the past was: the layout of the archived objects should be optimized for the heap size specified at dump time. Hence, the default CDS archive in the JDK is dumped with -Xmx128M so that it will be optimized for small workloads such as microservices. See https://github.com/openjdk/jdk/blob/2a579ab8392d30a35f044954178c788d16d4b800/make/Images.gmk#L117-L121

I am not referring to heap size, but the G1 region size. A user can create a base static archive with 128M heap and explicitly ask for larger region size than 1M and then try to use that image with a smaller region size. This will cause the archive heap to be relocated.
 Although highly unlikely scenario, but it can easily be handled by changing the alignment to always use `MIN_GC_REGION_ALIGNMENT` instead of using the current region size.

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

PR: https://git.openjdk.org/jdk/pull/12304