[master] RFR: 8304710: [Lilliput] Use forwarding table for sliding GCs [v5]

[Thomas Stuefe]

On Mon, 17 Apr 2023 18:50:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This changes the full-GC forwarding of Serial, Parallel, G1 and Shenandoah to use a forwarding table instead of the fancy SlidingForwarding that we had until now. SlidingForwarding has been problematic because it did not work universally, in particular we needed to disable the G1 serial full GC (the last last ditch GC, after parallel full GC failed). Also, sliding forwarding would not work when we start working towards 32bit headers.
>> 
>> The implementation of the forwarding table is a dense array of forwardings, with sorted entries and binary search. For details, have a look at the comments at the top of class ForwardingTable.
>> 
>> The change also greatly reduces the upstream diff.
>> 
>> In G1 I added a little code to count the marked objects in each region by counting bits in the mark-bitmap.
>> 
>> In Serial GC I likewise added some code to count new vs old objects during full-GC marking. Here there would be the alternative to treat the heap as a single region, and count marked objects without distinguishing old vs young. The problem is that old is allocated in higher memory than young, and the full-GC compacts old-gen first, and then young-gen, which breaks the assumption in ForwardingTable, which leads to very slow forwarding insertions. I also tried to simply swap the old and young reserved memory, and that is possible, but triggers all sorts of related changes where the memory order is implicitely used for stuff like is_in_young() etc.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Hashtable with Robin Hood hashing
>  - Use hashtable

What would be the worst case native memory consumption?

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

PR Comment: https://git.openjdk.org/lilliput/pull/83#issuecomment-1514895369