RFR: JDK-8188058: SATB queue set should initialize and manage their own locks
Roman Kennke
rkennke at redhat.com
Wed Aug 8 18:41:34 UTC 2018
Ok, that sounds kindof reasonable (still not a fan of global structures and central knowledge, but oh well...).
In Shenandoah we added UseShenandoahGC to the conditional for those locks. We'll upstream that when time comes. I'll close this bug then.
Thanks and cheers,
Roman
Am 8. August 2018 20:02:52 MESZ schrieb Kim Barrett <kim.barrett at oracle.com>:
>> On Aug 8, 2018, at 9:51 AM, Roman Kennke <rkennke at redhat.com> wrote:
>>
>>
>> Currently there are 3 locks related to SATB queues, and they are
>> declared and defined globally in mutexLocker.hpp|cpp. They are only
>> initialized inside an if (UseG1GC) block. This is slightly
>problematic
>> when another GC (e.g. Shenandoah) also needs to use SATB and their
>> respective locks.
>> In any case, it seems much cleaner to make those locks private in
>> SATBQueueSet (or PtrQueueSet) and initialize them there and not
>expose
>> it to the world to begin with.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8188058
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8188058/webrev.00/
>>
>> It could probably be taken further and also do something similar to
>> DirtyCardQueue, but it is *much* more hairy and probably better
>handled
>> as separate refactoring task.
>>
>> What do you think?
>> Can I get reviews?
>>
>> Thanks, Roman
>
>I don't think this change should be made.
>
>Mutexes and monitors are (mostly) declared and defined in one central
>place (mutexLocker.[ch]pp) intentionally. This provides a global view
>of them and their relative lock ranks in one place. And these locks
>in particular have super-special ranking. Squirrelling them away in
>some GC-specific files would not be helpful for that.
>
>They are presently only referred to by G1-specific code. Solutions to
>the conditional definition include adding Shenandoah to the
>conditionalization, adding similar Shenandoah-specific mutexes for use
>by Shenandoah (not my favorite, but mentioned for completeness), or
>remove the conditionalization.
>
>(I described this change to Coleen, and she had the same response.)
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
More information about the hotspot-gc-dev
mailing list