RFR (M): 8201491: G1 support for java.lang.ref.Reference precleaning

Thomas Schatzl thomas.schatzl at oracle.com
Thu Apr 26 09:36:35 UTC 2018

Hi all,

  can I have reviews for this change that implements reference
precleaning like CMS for G1?

In absence of fully concurrent reference processing this seems to be a
very good tradeoff between effort and improvement in some cases.

Since it is planned to be obsoleted in the future, and I do not expect
other new collectors to implement it (Shenandoah will likely go to
fully concurrent as well, Z afaik already has concurrent Reference
processing, and CMS is on its way out), I added a G1 specific
experimental option called "G1UseReferencePrecleaning" defaulting to
true (enabled).

It is also single-threaded, although it could be extended to MT
processing fairly easily. Again, a compromise between effort and
expected gain.

Contrary to CMS, the yield check interval is very high (after every
Reference), so it won't hold up pause requests, which may be a frequent
reason to disable it.

I spent like two days trying to find and convince myselves about a
fast-to-check and 100% reliable condition that would allow fine-grained 
yield checks with CMS too, however there was none I could find.
At least I am currently almost confident that this was the exact
problem why CMS implements yielding as is. I defer fixing this for CMS
to the community if they want it, i.e. implementing
CMSPrecleanRefsYieldClosure::should_return_fine_grain(), and
potentially replacing ::should_return() in the code.

Precleaning may lengthen the concurrent cycle time once more in case of
millions of References around as it is single threaded, however
typically this also decreases the Remark pause by magnitudes then.

I do not expect that to be an issue with almost all workloads as if you
have many References, the (Remark) pause time problem is typically more
 of an issue.

hs-tier1-5, *many* times Kitchensink reference stress test


More information about the hotspot-gc-dev mailing list