RFR: 8184751: Provide thread pool for parallel safepoint cleanup
rkennke at redhat.com
Tue Jul 25 10:15:00 UTC 2017
I have discussed this with Robbin Ehn offline. There is not much
interest in this change from Oracle engineering to have this upstream.
Unless somebody speaks up, I will close the bug and withdraw the review
by the end of today.
I will build this into Shenandoah-only instead in this case.
> This is a follow-up to 8180932: Parallelize safepoint cleanup, which
> should land in JDK10 real soon now.
> In order to actually be able to parallelize safepoint cleanup, we now
> need the GC to provide some worker threads.
> In this change, I propose to create one globally (i.e. for all GCs) in
> CollectedHeap, if ParallelSafepointCleanupThreads>1. The flag defaults
> to 0, which means it's doing cleanup using the VMThread (i.e. exactly
> current behaviour).
> We have already discussed this, and came to the conclusion that it does
> not really make sense to share the GC's worker threads here, because
> they may not be idle, but only suspended from concurrent work (i.e. by
> SuspendibleThreadSet::synchronize() or similar).
> What do you think?
More information about the hotspot-runtime-dev