RFR(S) 8225813: Shenandoah: Obsolete ShenandoahSuspendibleWorkers flag, as suspendible workers are required

Roman Kennke rkennke at redhat.com
Sun Jun 16 11:27:29 UTC 2019


Hi Zhengyu,

So as far as I can see, we are looking at 2 potential issues:

- Non-GC safepoint work might use our GC workers. This would only
possibly be heap-iteration, and as far as I remember, heap-iteration is
single-threaded and uses the VMThread. Besides: if this would happen,
we'd already have the problem. I don't think this is the case.
(Safepoint cleanup has this problem, and we use a separate thread pool
for precisely this reason.)

- Non-GC safepoint work needs to look at GC roots, and concurrent
processing of GC roots might conflict with that.

As far as I see it, this problem could also be solved by employing the
correct barriers. I believe this only affects heap-iteration. So when
heap-iteration scans the GC roots (during conc-evac), it needs to do the
LRB to avoid exposing from-space-objects in the iteration. Later on,
when we also want to do concurrent cleanup, it also needs to filter
unreachable objects by not seeding the iteration with objects that are
unreachable (as per the marking bitmap, not the aux bitmap!).

I might be missing something there?

The reason why I'm looking at avoiding stopping GC threads at safepoints
is that it may introduce additional latencies when bringing Java threads
to (non-GC) safepoints like biased locking or deopt, by having them wait
for GC work (especially when we have non-interruptible not-quite-short
GC work like GC roots processing).

Roman

> On 6/15/19 9:26 PM, Zhengyu Gu wrote:
>> On 6/15/19 3:35 PM, Roman Kennke wrote:
>>> Can you give a little bit of explanation why workers need to be
>>> suspended at safepoints for concurrent root processing?
>>
>> Concurrent processing uses workers and safepoint parallel task also
>> utilizes workers, and shenandoah shares workers, so they can not overlap.
> 
> Should be more articulate. I don't mean GC safepoint parallel tasks,
> which can not overlap. But the tasks, such as, heap iteration that might
> utilize workers.
> 
> Also, heap iteration walks CLDG at a safepoint, that may interfere CLDG
> walking during concurrent CLDG evacuation.
> 
> -Zhengyu
> 
>>
>>
>> -Zhengyu
>>
>>>
>>> Other than that, the patch looks good.
>>>
>>> Roman
>>>
>>>> Please review this patch that makes suspendible workers required,
>>>> instead of optional, and obsoletes the corresponding flag.
>>>>
>>>> Suspendible workers are required for concurrent root processing.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225813
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~zgu/JDK-8225813/webrev.00/index.html
>>>>
>>>> Test:
>>>>    hotspot_gc_shenandoah (fastdebug and release)
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20190616/e37e3289/signature.asc>


More information about the hotspot-gc-dev mailing list