Reusing ZGC forwarding table for other GCs/Lilliput?

Roman Kennke rkennke at redhat.com
Fri May 21 14:56:25 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.

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




More information about the hotspot-gc-dev mailing list