RFR: Utilize parallel workers for GC tasks during safepoints

[Zhengyu Gu]

Hi Aleksey,

Please see comments inline.

On 11/21/2016 06:16 AM, Aleksey Shipilev wrote:
> Hi,
>
> On 11/18/2016 08:27 PM, Zhengyu Gu wrote:
>> The change allows Shenandoah GC to utilize parallel GC workers during
>> STW safepoints, without the restriction imposed by the number of
>> concurrent GC threads.
>>
>> The main purpose of the change is to allow us scale up/down GC
>> concurrent and parallel workers independently.
>>
>> 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.

> E.g. only modify the mark loop to have this:
>
>     if (!try_queue(q, cl) &&
>         !try_draining_an_satb_buffer(q) &&
>         !try_switching_queue(&q, cl) &&  <--- switch queue here
>         !try_to_steal(worker_id, cl, &seed)) {
>
> ...and then build everything else from there?
>
> 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?

Thanks,

-Zhengyu


>
> Thanks,
> -Aleksey
>