RFR: Utilize parallel workers for GC tasks during safepoints

[Roman Kennke]

Ok.

I was thinking setup in the ReferenceProcessor constructor, but this is
probably even better.

Go!

Roman


Am Montag, den 21.11.2016, 11:42 -0500 schrieb Zhengyu Gu:
> Hi Roman,
> 
> You are right, if ReferenceProcessor's active_mt_degress is setup
> properly,
> it should auto balance queues.
> 
> Updated Weberv:
> http://cr.openjdk.java.net/~zgu/shenandoah/workers/webrev.01/
> Test:
> 
> Reran jcstress with fastdebug jdk.
> 
> Thanks,
> 
> -Zhengyu
> On 11/21/2016 08:39 AM, Roman Kennke wrote:
> > Am Montag, den 21.11.2016, 07:25 -0500 schrieb Zhengyu Gu:
> > > Hi Roman,
> > > 
> > > Thank you for the reviewing.
> > > 
> > > Coming out of concurrent phase, all queues should be empty.
> > > So at final mark phase, N par == N queue.
> > Duh. Ok :-)
> > 
> > But I have one more comment: in weak_refs_work() you explicitely
> > balance the queues. As far as I know, this should happen
> > automatically
> > if you set up the ReferenceProcessor correctly. You currently set
> > it up
> > for max_workers for both processing and discovery, but it should be
> > conc_workers for discovery and par_workers for processing. Right? 
> > 
> > Infact, I think we probably don't need a global ReferenceProcessor,
> > it
> > could be set up before each marking cycle, and also could be set up
> > differently for mark-compact (where we want both discovery and
> > processing to use par-workers, and atomic discovery too).
> > 
> > /Roman
> > 
> > > (final_mark_loop(), it actually does not need to claim_next(),
> > > I should convert that to assert(extra_queue->is_empty() ....)
> > 
> > > 
> > > -Zhengyu
> > > 
> > > 
> > > On 11/21/2016 05:47 AM, Roman Kennke wrote:
> > > > Hi Zhengyu,
> > > > 
> > > > I like it!
> > > > 
> > > > For going from N par threads to M conc threads, you let the
> > > > conc
> > > > threads claim the extra queues. For the other direction (i.e.
> > > > final-
> > > > mark), are you relying on stealing to see the extra par queues?
> > > > Fine to commit.
> > > > 
> > > > /Roman
> > > > 
> > > > Am Freitag, den 18.11.2016, 14:27 -0500 schrieb Zhengyu Gu:
> > > > > 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/we
> > > > > brev
> > > > > .00/
> > > > > 
> > > > > 
> > > > > Tests:
> > > > > 
> > > > > - jcstress (fastdebug)
> > > > > - Shenandoah GC test (fastdebug and release)
> > > > > - SPECjbb (fastdebug and release)
> > > > > - SPECjvm (fastdebug)
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > -Zhengyu
> > > > >