RFR: 8212748: ZGC: Add reentrant locking functionality

[Erik Österlund]

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