[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


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 
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!




More information about the hotspot-gc-dev mailing list