RFR(S): Merge GC thread pools

[Zhengyu Gu]

On 02/13/2017 03:20 PM, Roman Kennke wrote:

> For mark-compact, you setup workers once for marking and then again for
> the rest? Any specific reason for that? Else I think it should be set
> up once for everything in mark-compact.

The rest phases are proportional to live set size, which is obtained after marking.

Maybe I missed something, what other factors should be considered for phase 2, 3, and 4?

Thanks,

-Zhengyu


> Roman
>
> Am Montag, den 13.02.2017, 15:05 -0500 schrieb Zhengyu Gu:
>> This is the revised webrev that contains further clean up for
>> UseDynamicNumberOfGCThreads support.
>>
>> Now, the calculation of the number of workers for each GC phase is
>> moved up to the top of the phase.
>> Once setup, it expects all sub-routines are used active_workers for
>> the GC tasks.
>>
>> ConcGCThreads and ParallelGCThreads are still honored via.
>> ShenandoahCollectorPolicy::calc_xxxx() methods.
>>
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/single-worker/webr
>> ev.01/
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>
>> On 02/13/2017 10:22 AM, Zhengyu Gu wrote:
>>> I intended to update workers calculation in followup patch.
>>>
>>> You are right, without that changes, this messes up conc/parallel
>>> workers.
>>>
>>> I will combine the two patches, and update the webrev later.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>
>>> On 02/11/2017 02:55 AM, Aleksey Shipilev wrote:
>>>> On 02/10/2017 09:37 PM, Zhengyu Gu wrote:
>>>>> http://cr.openjdk.java.net/~zgu/shenandoah/single-worker/webrev
>>>>> .00/
>>>> I was thinking that after this merge, we can still use
>>>> ParallelGCThreads and
>>>> ConcCGThreads to limit parallelism of concurrent and parallel
>>>> phases.
>>>> Is this
>>>> handled now?
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>