RFR: 8296263: Uniform APIs for using archived heap regions

[Ioi Lam]

On Mon, 7 Nov 2022 19:56:09 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> While JDK-8296344 aims at decoupling the code at dump time, my aim with this PR is to achieve the same at run time by having GC-agnostic APIs. Moreover, the dump time mechanism should not affect the APIs used for mapping regions at run time (though the implementation may need to be adjusted).

I think it depends on how we want to change the dump time operations. If we decide to go with a single contiguous block, then the API for mapping this block into the runtime heap will look very different than what you have today:


bool ArchiveHeapLoader::get_heap_range_for_archive_regions(ArchiveHeapRegions* heap_regions, bool is_open) {
  if (Universe::heap()->alloc_archive_regions(heap_regions->dumptime_regions(),
                                           heap_regions->num_regions(),
                                           heap_regions->runtime_regions(),
                                           is_open)) {


Also, we should probably record the region boundary information in the archived objects. Something like "objects never span across 1MB boundaries". This may need to be passed to the runtime mapping API, so incompatible collectors (i.e., one uses 512KB regions) can reject the archived objects.

One of my goal for JDK-8296344 is to optimize the archived objects for the collector chosen at dump time. For example, if you dump with SerialGC, the archived objects can be mapped efficiently without relocation when SerialGC is also chosen at run time, but may require relocation if G1 is chosen at run time. I am not sure if how this would affect the runtime mapping API. Maybe some sort of preference would need to be indicated.

I think it would be best for us to think about the whole picture before committing to a design. Timing wise, I think we missed the JDK 20 release anyway, so we should have plenty time to come up with a good design for JDK 21.

I also would like to hear from folks in our GC team. @tschatzl @stefank

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

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