[16] RFR: 8248391: Unify handling of all OopStorage instances in weak root processing

Roman Kennke rkennke at redhat.com
Mon Jun 29 15:14:12 UTC 2020

Hi Erik,

This is great stuff.
I've reviewed the Shenandoah parts -- they look good to me.

I'll try to review the rest of it later this week.


> 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