[16] RFR: 8248391: Unify handling of all OopStorage instances in weak root processing
Erik Österlund
erik.osterlund at oracle.com
Fri Jun 26 13:06:03 UTC 2020
Hi,
Today, when a weak OopStorage is added, you have to plug it in
explicitly to ZGC, Shenandoah and the WeakProcessor, used by Shenandoah,
Serial, Parallel and G1. Especially when the runtime data structure
associated with an OopStorage needs a notification when oops die. Then
you have to explicitly plug in notification code in various places in GC
code.
It would be ideal if this process could be completely automated.
This patch allows each OopStorage to have an associated notification
function. This is a callback function into the runtime, stating how many
oops have died this GC cycle. This allows runtime data structures to
perform accounting for how large part of the data structure needs
cleaning, and whether to trigger such cleaning or not.
So the interface between the GCs to the OopStorage is that during weak
processing, the GC promises to call the callback function with how many
oops died. Some shared infrastructure makes this very easy for the GCs.
Weak processing now uses the OopStorageSet iterators across all GCs, so
that adding a new weak OopStorage (even with notification functions)
does not require touching any GC code.
Kudos to Zhengyu for providing some Shenandoah code for this, and
StefanK for pre-reviewing it. Also, I am about to go out of office now,
so StefanK promised to take it from here. Big thanks for that!
CR:
https://bugs.openjdk.java.net/browse/JDK-8248391
Webrev:
http://cr.openjdk.java.net/~eosterlund/8248391/webrev.00/
Thanks,
/Erik
More information about the hotspot-gc-dev
mailing list