RE: RFR: 8184751: Provide thread pool for parallel safepoint cleanup
We might be interested in seeing this in Par GC and/or G1 at some point, but we can push that when the time comes.
Thanks for working this issue though Roman, looking forward to trying it out in Shenandoah.
- Derek White, Cavium
> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> [hidden email]] On Behalf Of Roman Kennke
> Sent: Tuesday, July 25, 2017 6:15 AM
> To: hotspot-gc-dev openjdk.java.net <[hidden email]>
> Cc: [hidden email] > Subject: Re: RFR: 8184751: Provide thread pool for parallel safepoint cleanup
> 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).
> > http://cr.openjdk.java.net/~rkennke/8184751/webrev.00/ > > <http://cr.openjdk.java.net/%7Erkennke/8184751/webrev.00/>
> > What do you think?
> > Roman