RFR: 8212748: ZGC: Add reentrant locking functionality
Erik Österlund
erik.osterlund at oracle.com
Thu Oct 25 16:20:06 UTC 2018
Hi Per,
Thanks for having a look at this.
On 2018-10-25 17:27, Per Liden wrote:
> Hi Erik,
>
> On 2018-10-25 15:44, Erik Österlund wrote:
>> Hi,
>>
>> ZGC needs a per-nmethod lock to be used for concurrent IC cleaning,
>> protecting misaligned oops from concurrently being patched by nmethod
>> entry barriers, and read using CompiledMethod::is_unloading(), with
>> interactions crossing JavaThreads and non-Java threads. This patch
>> adds that utility.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8212748/webrev.00/
>
> I'd like to suggest that ZReentrantLock doens't inherit from ZLock, but
> that it instead has a ZLock. And that ZLocker is adjusted to take a T*
> instead of a ZLock*.
Wouldn't it be annoying that you can't use a plain ZLocker then, but
instead would have to use ZLocker<ZLock>? I'm not sure I see the
advantage of that approach, only a usability disadvantage. I'm not
opposed either though if you prefer it to be done in that way.
> Also, I'm not sure I see the need for the reentrant_lock() function.
> Shouldn't we just have a lock counter and let lock/unlock do the right
> thing?
That is a possibility indeed. However, there are contexts where the lock
is not (and must not be) taken in a reentrant way, and it is an
important assumption that it is in fact not reentrant, and I want it to
not work if that assumption is wrong. And I wanted that to be the
default and be the behaviour when using the ZLocker. Plus given that
motivation, I also don't know if I want the extra counter state that
seems unnecessary for the contexts where reentrancy is handled.
Again, I'm not opposed to what you are suggesting, just trying to weigh
the pros and cons. What do you think?
Thanks
/Erik
> cheers,
> Per
>
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8212748
>>
>> Thanks,
>> /Erik
More information about the hotspot-gc-dev
mailing list