RFR: 8212748: ZGC: Add reentrant locking functionality

[Kim Barrett]

> On Oct 25, 2018, at 12:20 PM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> 
> 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.

For what its worth, that’s exactly how the similar C++11 facility works, e.g. one says

    std::lock_guard<std::mutex> lk(m);
or
    std::lock_guard<std::recursive_mutex> lk(rm);