RFR: 8310160: Make GC APIs for handling archive heap objects agnostic of GC policy [v2]

[Ioi Lam]

On Tue, 20 Jun 2023 15:56:57 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecessary assert and condition for UseG1GC
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Rename CollectedHeap::reserved() to CollectedHeap::reserved_range()
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Rename alloc_archive_space to allocate_archive_space
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> It's a bit disappointing for a PR aiming to make heap archiving GC agnostic, to make assumptions about GC internal memory layout, that doesn't apply to all collectors.
> We have discussed previously with @iklam an approach where materializing archived objects uses the normal object allocation APIs. That would for real make the heap archiving mechanism GC agnostic. I would rather see that being prototyped, than a not GC agnostic approach that we might throw away right after it gets integrated, in favour of the more GC agnostic approach.

Based on discussion with @fisk, I created an RFE for investigating his idea. Please see https://bugs.openjdk.org/browse/JDK-8310823

It seems quite promising to me, and will greatly reduce (or eliminate) the interface between CDS and the collectors.

I would like to keep the current performance as possible, so I am leaning towards having an API for CDS to tell the collector about preferred location of the archived objects, to allow mmap'ing and reduce/avoid relocation. But such an hinting API will be much smaller than the ones proposed by this PR.

(We'd also need an reverse API for the collector to tell CDS what the preferred address would be, during CDS dump time).

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

PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1604793890