RFR: 8212748: ZGC: Add reentrant locking functionality

Erik Österlund erik.osterlund at oracle.com
Tue Nov 20 07:53:20 UTC 2018


Hi Per,

Looks good.

Thanks,
/Erik

On 2018-11-20 08:45, Per Liden wrote:
> Hi,
> 
> On 10/26/18 2:00 AM, Kim Barrett wrote:
>>> 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);
>>
> 
> Erik and I discussed this some more and we ended up with the following 
> patch:
> 
> http://cr.openjdk.java.net/~pliden/8212748/webrev.0/
> 
> cheers,
> Per



More information about the hotspot-gc-dev mailing list