RFR: 8270489: Support archived heap objects in EpsilonGC

[Igor Ignatyev]

On Tue, 10 Aug 2021 19:57:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **Overview:**
> 
> This is the first step for supporting archived heap objects for non-G1 collectors. We are doing it for EpsilonGC first to iron out the API between GC and CDS. Also we can implement most of the common code (such as copying archived objects into heap), without impacting the overall system stability.
> 
> - Only G1 can write archive heap objects into the CDS archive.
> - Archived objects are "mapped" by G1, but the mapping operation is quite complex.
> - All other collectors will "load" the archive objects, which is much simpler to implement. The trade off is a small start-up penalty and no heap sharing.
> 
> Most of the loading code is implemented in heapShared.cpp. The collectors just need to implement the following two CollectedHeap::APIs in 
> 
> 
>   virtual bool can_load_archived_objects();
>   virtual HeapWord* allocate_loaded_archive_space(size_t size); // typically return a block in old gen
> 
> 
> **Implementation:**
> 
> - Allocate (from the old gen) a buffer that's large enough to contain all the archived heap objects.
> - Inside the CDS archive file, the heap objects are usually divided into 2~4 disjoint regions (there are gaps between them).
> - Copy every region in to the buffer consecutively, without any gaps.
> - Relocate all the oop fields in all the copied objects, taking into account of the gap removal.
> - The archived strings may be relocated by a full GC, but the CDS "shared string table" cannot handle relocation, so we copy the archived strings into the dynamic string table.
> 
> **Benchmarking:** 
> 
> We can see significant start-up improvement because the module graph can be loaded from CDS.
> 
> 
> $ perf stat -r 40 java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx256m -version
> 
> Before:  43.1ms
> After:   30.2ms
> 
> 
> Testing:
> 
> - Some general clean up of the test cases.
> - Added support for `-vmoptions:-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`: we dump the CDS archive with G1 so we have an archived heap, but run with EpsilonGC to test the new loading code.
> - Added a mach5 task to run all CDS tests with the above config. Incompatible test cases are tagged with `@require vm.gc == null`. See changes in CDSOption.java and VMProps.java

Changes requested by iignatyev (Reviewer).

test/jtreg-ext/requires/VMProps.java line 303:

> 301:      * @param map - property-value pairs
> 302:      */
> 303:     protected void vmGCforCDS(SafeMap map) {

as this might impact any tests which use `vm.gc` and not just CDS tests, I think it would be better to first check if `vm.gc` is(will be) set to non-null value. given it's done by jtreg in another class and using another instance of Map, we can't just call `Map::contains` and have to check if GC has been explicitly selected by smth like `GC.selected().isSelectedErgonomically()`.

it also might be a good idea to comment at L#124 to indicate that this method overrides `vm.gc` value.

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

PR: https://git.openjdk.java.net/jdk/pull/5074