[master] RFR: 8346011: [Lilliput] Compact Full-GC Forwarding [v4]

[Roman Kennke]

On Tue, 21 Jan 2025 12:51:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The current forwarding scheme that is used during full-GC overrides much of the mark-word. This is a problem for current compact headers when the heap is larger than 8TB (in which case we currently disable compact headers altogether) and becomes a much worse issue with 4-byte-compact-headers, because it would override the compressed class-pointer in the upper header bits.
>> 
>> This implementation uses a side-table (currently 1/512th of the heap size) to store part of the target addresses, and 9 bits in the header for the rest of it. For the full description of the algorithm, see top of fullGCForwarding.hpp.
>> 
>> Some performance testing results: https://gist.github.com/rkennke/5a53d21337fc6e696041062d6b972dd6
>> Interpretation: The new full-GC forwarding is slightly slower across the board. The different is almost completely a constant ~10ms. This corresponds to the setup costs of allocating and clearing the side-table. That cost could be reduced by allocating and clearing the table up-front, when the GC gets initialized, and then only ever clearing the table when full-GC is finished. That brings down the numbers to almost exactly baseline level, but I think we wouldn't want to hold on to that memory all the time, especially not in G1 and Shenandoah, where full-GC is an exceptional mode that is not intended to run frequently.
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier1 +UseSerialGC
>>  - [x] tier1 +UseParallelGC
>>  - [x] tier1 +UseShenandoahGC
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make all constants constexpr

Thanks!

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

PR Comment: https://git.openjdk.org/lilliput/pull/191#issuecomment-2607028019