RFR: Enforce GC workers constraint

[Zhengyu Gu]

On 09/06/2018 03:32 PM, Roman Kennke wrote:
> Am 06.09.2018 um 21:25 schrieb Aleksey Shipilev:
>> On 09/06/2018 08:53 PM, Zhengyu Gu wrote:
>>> CMS and G1 enforce GC worker constraint:
>>>    Parallel workers >= Concurrent workers
>>>
>>> Shenandoah should probably do so.
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/gc_worker_constraints/webrev.00/
>>
>> The patch is okay, and probably sensible. But do we need to do this? Does it allow for any
>> convenience in our code? I can mind-wrestle the example where having more concurrent threads (e.g.
>> 4) than parallel (e.g. 2) is beneficial. Seems inconvenient to tie them together without the reason.
>>
Well, do we really have cases that want to have more concurrent threads 
than parallel? If not, this constraint does help eliminate some code to 
balance queues in parallel phases.

> 
> I was thinking the same.
> 
> The issues are probably:
> - we need to keep testing this weird case to ensure it doesn't get broken
> - IIRC, we have some extra code block to deal with that case and
> re-balance the task queues when going from more conc-TQs to fewer
> par-TQs at the beginning of final-mark/final-traversal. We could wipe
> those blocks I think. Zhengyu probably knows better about this. However,
> if this is the case, those code blocks should be wiped together with the
> rest of the patch.

In case of concurrent threads always <= parallel threads, then we can 
eliminate queue reservation and extra queue claiming, which all done in 
parallel phases.

Thanks,

-Zhengyu


> 
> Roman
>