RFR: Utilize parallel workers for GC tasks during safepoints

[Aleksey Shipilev]

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?

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()?


Thanks,
-Aleksey