RFR(S): Merge GC thread pools
Zhengyu Gu
zgu at redhat.com
Mon Feb 13 20:47:38 UTC 2017
On 02/13/2017 03:31 PM, Roman Kennke wrote:
> Am Montag, den 13.02.2017, 15:28 -0500 schrieb 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?
> Maybe I don't understand all of it yet.
>
> To me it looks like you calculate num-threads for init-marking, which
> is meant for scanning roots real quick. But then it's used for marking
> all the heap, which is, as you say, LDS-size dependend. I would throw a
> generous number of threads on it. ;-)
I am not saying that I got heuristics right :-) and probably not.
But for these 3 phases, that only factor, I can see, is LDS size.
However, we can tune size/worker ratio if it the number comes out low.
-Zhengyu
> Roman
>
>> 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/we
>>>>>>> brev
>>>>>>> .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
>>>>>>
>>
More information about the shenandoah-dev
mailing list