RFC: CDS improvements with archived Java heap objects

[Ioi Lam]

GC folks,

Project Leyden is likely to make extensive use of archived Java heap 
objects. Therefore, we are planning to improve the support for archived 
Java heap objects in CDS.

Here's a rough plan that I have in mind. I'd like to run this by 
everyone to make sure it makes sense.

Goals:

- Uniform support of CDS for all collectors
- Minimize the code needed for each collector to support CDS


As of JDK 20, we have the following limitations

- CDS archive heap dumping is supported only by G1
- G1 has a special allocation routine to allocate
   space in the heap (inside a safepoint) as the source image
   of the archive heap.
- mmap() of the archive heap is supported only in G1, with
   special "archive" region types that have special collection rules.
   For example, the "closed archive" regions are not evacuated (and not
   even marked ??)
- SerialGC and ParallelGC doesn't use mmap(), but would read the
   archive heap into the old generation.


Plans:

[1] JDK-8296344: Remove G1 dependency for writing the archive heap.
     I already have a working prototype.

[2] JDK-8298048: Consolidate the whole archive heap into a
     contiguous block. (Currently, the archive heap is divided into
     at least two blocks, one of "open" type and one of "closed" type).

     This will make it easy to mmap the archive heap into different
     collectors.

     As part of this step, we remove G1's "archive" region types.
     The archive heap is mmap'ed into regular G1 regions. Thereafter,
     these objects would work just as if they were allocated normally.

     One of the original idea of having a G1 "closed archive" region type
     (which contains only strings from the intern strings table) is
     that it might speed up collection. However, in practice, we are only
     talking about several hundred KB of data which probably won't
     make any difference to justify the complexity.

     (We'll run benchmarks to check make sure there's no regression).

[3] JDK-8296263: implement mmap of the archive region for other
     collectors. (This would be broken down in multiple RFEs).

     We expect the implementation to be fairly simple. Each collector just
     needs to reserve a contiguous block (in its "old space", if applicable)
     and mmap into it.

     The objects in the archive are padded such that none of them would 
cross
     256KB boundaries, so they should be compatible with region-based 
collectors
     such as G1 and Shenandoah (which have minimal 1MB and 256KB region
     alignments, respectively).


To keep this mail short, I have left out many details. Please feel free 
to ask for
explanations and clarifications. I would love to hear your feedback and 
suggestions.

Special thanks to Ashutosh Mehra. His initial PR for JDK-8296263 
provided impetus
for this work. He has also provided valuable input and design ideas when 
reviewing
my prototypes.

Thanks
- Ioi