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

[Thomas Schatzl]

Hi,

  ping for a reviewer... :)

I am aware that the option name is not the shortest
("G1UseReferencePrecleaning") but something like "G1Precleaning" seems
too obtuse. Maybe "G1UseRefPrecleaning"? (We abbreviate "Reference" to
"Ref" in other switches already).

Thanks,
  Thomas

On Thu, 2018-04-26 at 11:36 +0200, Thomas Schatzl wrote:
> 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.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201491
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8201491/webrev/
> Testing:
> hs-tier1-5, *many* times Kitchensink reference stress test
> 
> Thanks,
>   Thomas
>