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