RFR: 8293650: Shenandoah: Support archived heap objects [v4]

[Roman Kennke]

On Wed, 14 Aug 2024 10:01:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Work around 32-bit build failure

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2509:

> 2507:   // Pull the constant here, since it is only available when INCLUDE_CDS_JAVA_HEAP is defined.
> 2508:   const size_t min_gc_region_align = 1 * M;
> 2509: #if INCLUDE_CDS_JAVA_HEAP

It makes me wonder if the whole body should perhaps go inside the INCLUDE_CDS_JAVA_HEAP block. It is only ever called from ArchiveHeapLoader, and that doesn's even exist without INCLUDE_CDS_JAVA_HEAP. I leave that up to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1717265883