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

[Ioi Lam]

On Wed, 8 Feb 2023 14:31:03 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> 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.

Since we have a small amount of archived objects, if we always use MIN_GC_REGION_ALIGNMENT to decide the requested location, it will always be 1MB below the top of the heap.  As a result, we will always relocate when running with larger heaps (or larger G1HeapRegionSize):


$ java -Xshare:dump -Xmx128m -XX:G1HeapRegionSize=1m 
$ java -Xmx128m -XX:G1HeapRegionSize=4m -Xlog:cds --version
[.....]
[0.002s][info][cds] CDS archive was created with max heap size = 128M, and the following configuration:
[0.002s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
[0.002s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
[0.002s][info][cds]     heap range = [0x00000000f8000000 - 0x0000000100000000]
[0.002s][info][cds] The current max heap size = 128M, HeapRegion::GrainBytes = 4194304
[0.002s][info][cds]     narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 0
[0.002s][info][cds]     narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0
[0.002s][info][cds]     heap range = [0x00000000f8000000 - 0x0000000100000000]
[0.002s][info][cds] Heap region ca0 = 0x00000000fff00000 - 0x00000000fff83000 =   536576 bytes
[0.002s][info][cds] Heap region oa0 = 0x00000000ffe00000 - 0x00000000ffe79000 =   495616 bytes
[0.002s][info][cds] CDS heap data relocation delta = 0 bytes
[0.002s][info][cds] CDS heap data needs to be relocated lower by a further 3145728 bytes to -3145728 to be aligned with HeapRegion::GrainBytes


Because the archive regions are pinned, we want to always put them at the absolute top end of the heap to avoid fragmentation. 

With this PR, I think we should keep the current behavior (which has not been changed by this PR) -- the requested location of the archive objects should be optimized for the heap parameters specified during dump time.

However, after [JDK-8298048](https://bugs.openjdk.org/browse/JDK-8298048), we will use G1's "old" regions which aren't pinned. So we can afford to have a few empty regions above the archive regions.

In that case, for G1, the requested base should be (heap_top - max_region_size), where  max_region_size should be 8M. This will allow all heap sizes up to 16GB to map the archive regions without relocating the pointers.

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

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