[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.
Thanks,
Roman
> 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