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

[Ioi Lam]

On Tue, 20 Jun 2023 16:33:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> 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.
>
>> 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.
> 
> There are a few problems with using the regular heap allocation API to reserve space for the archived objects:
> 
> - On G1, if the required (contiguous) space is larger than a single G1 region, it will end up inside a huge region
> - If we instead attempt to allocate several blocks, each the size of a regular G1 region, there's no guarantee that these blocks would be contiguous. Fixing the pointers across discontiguous blocks would be messy
> - We could allocate one block for each individual archived object. This will be most portable across GCs, but the pointer relocation will be slow. (Also, we have to handle the possibility of collecting in the middle of allocating these blocks)
> - If we allocate one or multiple larger blocks, and fill them with the archived objects, we still need a per-GC specific way to fix-up these blocks at the very end. This is what we are doing today with Serial and Parallel:
>     - https://github.com/openjdk/jdk/commit/6a573b888d4d3322b9165562f85e1b7b781a5ff1#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626
>     - https://github.com/openjdk/jdk/commit/234c17e8ff7b9b9713e9fded693381f985d34d2a#diff-b8bae64d029923161d88b761e6b775454924218e5f27f30130610da56d0bbefd

> > 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.
> 
> There are a few problems with using the regular heap allocation API to reserve space for the archived objects:
> 
> * On G1, if the required (contiguous) space is larger than a single G1 region, it will end up inside a huge region
> * If we instead attempt to allocate several blocks, each the size of a regular G1 region, there's no guarantee that these blocks would be contiguous. Fixing the pointers across discontiguous blocks would be messy
> * We could allocate one block for each individual archived object. This will be most portable across GCs, but the pointer relocation will be slow. (Also, we have to handle the possibility of collecting in the middle of allocating these blocks)
> * If we allocate one or multiple larger blocks, and fill them with the archived objects, we still need a per-GC specific way to fix-up these blocks at the very end. This is what we are doing today with Serial and Parallel:
>   
>   * [6a573b8#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626](https://github.com/openjdk/jdk/commit/6a573b888d4d3322b9165562f85e1b7b781a5ff1#diff-d53bf148d2758636cb8c6a54595515610a4c52d953e23e7bfdeef1106c14f626)
>   * [234c17e#diff-b8bae64d029923161d88b761e6b775454924218e5f27f30130610da56d0bbefd](https://github.com/openjdk/jdk/commit/234c17e8ff7b9b9713e9fded693381f985d34d2a#diff-b8bae64d029923161d88b761e6b775454924218e5f27f30130610da56d0bbefd)

In the future, the Leyden project may prefer to have a "permanent" section of the archived objects that are never collected/moved. That would require more collector-specific code.

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

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