Reusing ZGC forwarding table for other GCs/Lilliput?

[Per Liden]

On 5/21/21 4:56 PM, Roman Kennke wrote:
> 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.

/Per

> 
> Or maybe there are other/better solutions to the problem that I 
> described above?
> 
> Please let me know what you think!
> 
> Thanks & have a nice weekend!
> Roman
>