RFR: 8305896: Alternative full GC forwarding [v10]

[Erik Österlund]

On Fri, 28 Apr 2023 14:00:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.
>
>> Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.
> 
> It only allocates a relatively small side-table that is number-of-regions * 2words. For G1 and Shenandoah, it uses the 'natural' GC regions. A typical number of regions would be 2048, so we'd get a side-table of 4096 * 2 * 8 = 64KB. If we assume a region-size of 2M (which seems at the lower end of the spectrum) then that heap would be 4GB. That's an overhead of 0.0016% if I counted correctly. Ultimately it depends on the workload, but I believe it is an acceptable overhead.
> 
> Also, the 'memory optimization' (compact object headers) would be benefitial for the common operation, i.e. *all situations*. This GC forwarding change is only relevant for full-GCs which is an exceptional situation. At least in Shenandoah we try very hard to avoid it altogether, for Serial and G1 it tends to happen once in a while, but IMO not often enough that 0.0016% overhead would be a concern.

> > Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.
> 
> It only allocates a relatively small side-table that is number-of-regions * 2words. For G1 and Shenandoah, it uses the 'natural' GC regions. A typical number of regions would be 2048, so we'd get a side-table of 4096 * 2 * 8 = 64KB. If we assume a region-size of 2M (which seems at the lower end of the spectrum) then that heap would be 4GB. That's an overhead of 0.0016% if I counted correctly. Ultimately it depends on the workload, but I believe it is an acceptable overhead.
> 
> Also, the 'memory optimization' (compact object headers) would be benefitial for the common operation, i.e. _all situations_. This GC forwarding change is only relevant for full-GCs which is an exceptional situation. At least in Shenandoah we try very hard to avoid it altogether, for Serial and G1 it tends to happen once in a while, but IMO not often enough that 0.0016% overhead would be a concern.

Sounds good.

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

PR Comment: https://git.openjdk.org/jdk/pull/13582#issuecomment-1527672618