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