RFR: Parallelize safepoint cleanup

[Erik Österlund]

On 2017-05-29 16:08, Roman Kennke wrote:
> Am 29.05.2017 um 15:39 schrieb Erik Österlund:
>> Hi,
>>
>> How do we feel about reusing the Parallel GC Threads work gang during
>> safepoint cleanup?
> I actually tried that, but failed, at least with Shenandoah, because...
>
>> We know that the Parallel GC Threads worker gang is idle then.
> Not Shenandoah :-) Shenandoah GC threads are currently happy to continue
> working during (non-GC) safepoints. One exception is the heap dumper,
> which currently requires some extra synchronization. If you know of any
> other safepoints that would require stopping concurrent GC threads
> (marking, evacuating or updating references) let me know. I haven't
> found any. Parallelizing safepoint cleanup might be a reason to
> implement GC thread safepointing though.

So perhaps one solution would be to have a 
SafepointSynchronize::worker_gang() that is initialized during 
bootstrapping. Then the GC can decide whether it wants to share its 
ParallelGCThreads worker gang, or do something else like creating a new 
worker gang.

> Another problem with this approach is that it's clearly GC dependend,
> and requires support (i.e. a worker thread pool) and coordination (i.e.
> pause-resume GC work) by the GC. For example, as Kirk pointed out,
> serial gc couldn't support that.

You typically use Serial GC because you don't want a bunch of worker 
gangs. I don't think safepoint cleanup is an exception to that.

>
>> This saves creating another gazillion threads and another JVM flag to
>> keep track of.
> It would only be a few threads. There's just not that much work to do.
> The prime scenario for this seems to be many- (like hundreds or
> thousands of) threads work loads, in which case it hardly matters to add
> some more to support more efficient cleanup.

I see your point. I am just a bit hesitant to adding new worker gangs 
with user configurable knobs unless there is no other way.

Thanks,
/Erik

> Roman
>