RFR: 8212748: ZGC: Add reentrant locking functionality

Kim Barrett kim.barrett at oracle.com
Wed Nov 21 13:45:45 UTC 2018


> On Nov 21, 2018, at 5:18 AM, Per Liden <per.liden at oracle.com> wrote:
> 
> Hi Kim,
> 
> On 11/20/18 9:37 PM, Kim Barrett wrote:
>>> 
>>> 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
>> ------------------------------------------------------------------------------
>> Is there a reason why this was not based on a pthread_mutex_t
>> configured with the PTHREAD_MUTEX_RECURSIVE attribute?  (Rather than
>> this "hand-rolled" recursion.)
>> ------------------------------------------------------------------------------
>> What is RecursiveZLock::is_owned for?  That might be why the RECURSIVE
>> attribute wasn't used, but since I don't see the point, except perhaps
>> for assertion checks.  Part of my question is, if is_owned is
>> desirable for recursive case, why not for ordinary?  A similar
>> implementation would seem to suffice.
> 
> Yes, is_owned() is used in some asserts, but more importantly it's used in few other cases too. The locking around concurrent class unloading is a bit messy, but in some contexts (which has multiple entry points) is_owned() is used to figure out if it's safe to do some operations because the thread has the lock, or if that should be postponed.
> 

That sounds rather icky.

Change looks good.





More information about the hotspot-gc-dev mailing list