RFR: Utilize parallel workers for GC tasks during safepoints

[Aleksey Shipilev]

On 11/21/2016 01:39 PM, Zhengyu Gu wrote:
> On 11/21/2016 06:16 AM, Aleksey Shipilev wrote:
>>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/workers/webrev.00/
>> The mark loop logic seems complicated. I have a design question: can't
>> we make worker re-associate with another queue in QueueSet when its
>> queue runs dry?
> 
> It kind of doing so, but at the end, it has to come back to "original"
> queue, because the closure takes "original" queue, can push new tasks
> into "original" queue.

Aw, right. That's unfortunate, I thought it would be possible for the
worker thread to bind the local queue and work with it. Ok then, this is
lesser evil.

>> This has the added benefit of draining the SATB buffers on the common
>> path, not after all excess queues are drained up. Or, at very least, we
>> might want to do try_draining_an_satb_buffer() in
>> SCM::concurrent_process_queues()?
> 
> I fail to see any benefit, can you explain? or we can drain satb buffer at
> the very beginning?

This is a concurrent marking loop, which is ran concurrently with
mutator, right? If so, delaying SATB processing to handle excess queues
might fill up SATB queue prematurely, since all GC workers are busy
draining the excess queues and not processing SATB at the beginning? I'd
think draining SATB during the excess queue processing is safer in this
regard.

Thanks,
-Aleksey