RFR: Parallelize safepoint cleanup

Robbin Ehn robbin.ehn at oracle.com
Thu Jun 15 12:10:03 UTC 2017


On 06/15/2017 12:49 PM, Andrew Haley wrote:
> On 29/05/17 15:16, Roman Kennke wrote:
>> I agree that having a single pool would be good. The current WorkGang
>> doesn't do it though, because we can't borrow threads while the GC is
>> doing work, at least not in a way that is GC agnostic (see my reply to
>> Robbin).
> 
> It would be nice, though, not to have to share worker threads between
> GC and other jobs if we didn't need todo so.  If we're on a
> large-scale multicore machine, we don't want to be trashing warm
> caches in idle cores unless it's forced on us by the lack of hardware
> resources.  We're not always short of cores, and the massively-
> scalable multi-core world is nearly upon us.
> 

I agree with your point: just because we have a single pool doesn't necessary mean we need to share the threads, but share heuristics.
We have some stuff in the pipeline that we would like to also be done in parallel during STW or/and concurrent, like the concurrent monitor deflation.
JFR have already moved most of the logic of out STW, so consider JFR + Shenandoah + concurrent deflation and invoking Arrays.parallelSort() (don't forget about compiler 
threads running also).
Now we may end up trashing caches just because we have no heuristics.

The solution is not obvious to me, that why, at least, I need to think about it. (JEP)

Thanks, Robbin



More information about the hotspot-gc-dev mailing list