[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