RFR: Parallelize safepoint cleanup

[David Holmes]

I missed this before replying earlier up the thread ...

On 30/05/2017 1:25 AM, Erik Österlund wrote:
> 
> 
> 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.

I think the best approach would be to factor out the "worker gang" into 
a more general purpose thread pool (of non-JavaThreads) which can be 
dynamically sized, buffer tasks during high demand etc ( as per 
java.util.concurrent.ThreadPoolExecutor). Thereby isolating the worker 
threads from any specific task they may be engaged for.

Cheers,
David
-----

>> 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
>>
>