RFR: Enforce GC workers constraint

[Zhengyu Gu]

Okay. Nevermind, we still need to deal dynamic workers, might have 
chance to calculate more concurrent threads than parallel threads (?)

I withdraw this RFR for now. But will see if possible to enforce the 
same constraint with dynamic workers.

-Zhengyu

On 09/06/2018 04:03 PM, Zhengyu Gu wrote:
> 
> 
> 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
>>