RFR: Utilize parallel workers for GC tasks during safepoints
Zhengyu Gu
zgu at redhat.com
Mon Nov 21 16:42:18 UTC 2016
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/webrev
>>>> .00/
>>>>
>>>>
>>>> Tests:
>>>>
>>>> - jcstress (fastdebug)
>>>> - Shenandoah GC test (fastdebug and release)
>>>> - SPECjbb (fastdebug and release)
>>>> - SPECjvm (fastdebug)
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
More information about the shenandoah-dev
mailing list