RFR (XXS): 8202829: Implement CollectedHeap::get_safepoint_workers() for G1

[Roman Kennke]

Sweet!

In Shenandoah GC we use a separate thread pool for this. I am trying to
remember why :-) It might have been because Shenandoah workers are not
suspending at safepoints. It might also have been because it is not
benefitial to throw that many workers on the safepoint cleanup. It might
be worth to evaluate the usefulness on large box / many threads setups,
and probably limit the number of workers to give to safepoint cleanup.

Other than that: go!

Roman


> Hi all,
> 
>   due to the recent RFR for ZGC I noticed that G1 would also benefit
> from implementing CollectedHeap::get_safepoint_workers().
> 
> It is a pretty trivial change for G1 as we already have/use a "hot"
> WorkGang that is always available during a safepoint.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202829
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8202829/webrev/
> Testing:
> hs-tier1-3
> 
> Results from random specjbb2015 runs:
> 
> Baseline for "safepoint cleanup tasks":
>               count: 1628
>                 min: 7.5e-05
>                 max: 0.0072682
>                 sum: 4.76701
>                 avg: 0.00292814 (+/-0.0016433)
>     95th percentile: 0.0054634
>     99th percentile: 0.0062773
>   99.9th percentile: 0.0072269
>  99.99th percentile: 0.0072682
> 
> With changes for "safepoint cleanup tasks":
>               count: 1772
>                 min: 9.24e-05
>                 max: 0.0014651
>                 sum: 1.33761
>                 avg: 0.000754861 (+/-0.000230524)
>     95th percentile: 0.0009985
>     99th percentile: 0.001097
>   99.9th percentile: 0.0012676
>  99.99th percentile: 0.0014651
> 
> So, some significant improvement here, although very small in total.
> Since it is such a simple change I guess we'll take it :)
> 
> I assume in the future the number of threads could be determined more
> cleverly depending on actual work.
> 
> Thanks,
>   Thomas
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180509/84537995/signature.asc>