Reusing ZGC forwarding table for other GCs/Lilliput?
Roman Kennke
rkennke at redhat.com
Tue May 25 10:47:20 UTC 2021
>> Hello GC folks,
>>
>> I am thinking about how to solve the following problem in Lilliput: I
>> am now at a point where I can store the compressed Klass* in the
>> object header. However, GCs are still using the current separate
>> (compressed) Klass* to restore the header after GC. If we were to get
>> rid of the Klass* word, then we'd have nothing to restore the Klass*
>> in the header from because it is overridden by the forwarding pointer.
>> This is only a problem that affects sliding GCs like Serial and
>> Parallel GC, and G1's and Shenandoah STW full-GCs. Relocating GCs (G1
>> concurrent and Shenandoah concurrent) don't have this because there we
>> have the to-space copy which carries the original header.
>>
>> One possible solution would be to preserve *all* marks (of moving
>> objects) instead of only those which have a hashcode or locking bits.
>> The advantage is that PreservedMarks is a very compact table and is
>> simple to manage. The downside is that if we preserve-marks we will
>> have a problem if we require the Klass* during GC, and we do, when we
>> scan the heap. Unless we use a mark bitmap for scanning, which is not
>> currently used in Serial/ParallelGC afaik.
>>
>> That's why I'm thinking that an external forwarding table to manage
>> forwarding information might be the best way to go. And since ZGC
>> already has a forwarding table for exactly that purpose, I am
>> wondering if it is generic enough to also be used outside ZGC, or if
>> there is anything intrinsic in its design that makes it only useful in
>> ZGC context, and we'd rather implement a more generic forwarding table
>> for other GCs.
>
> While reusing the concept might be a good idea, the actual code (i.e.
> ZForwardingTable/ZForwarding/ZForwardingEntry) will probably not be a
> great fit for other GCs. These classes carry quite a lot of ZGC specific
> information with ties to data structures like ZPage, ZVirtualMemory,
> ZGranuleMap, etc.
Ok thanks, Per! I will study it and make up my mind how to proceed!
Roman
More information about the zgc-dev
mailing list