RFR (S) 8164207: Checking missing load-acquire in relation to _pd_set in dictionary.cpp

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Aug 30 13:49:55 UTC 2017



On 8/30/17 7:54 AM, David Holmes wrote:
> On 30/08/2017 9:14 PM, coleen.phillimore at oracle.com wrote:
>>
>> Hi, I changed the edit for David to only use ordering semantics in 
>> the places where needed in the lock free access to pd_set. Since only 
>> contains_protection_domain is read lock free, it should be ok.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8164207.04/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8164207
>
> Thanks Coleen. This looks good to me.

Thanks, David.

Coleen

>
> David
> -----
>
>> Thanks,
>> Coleen
>>
>> On 8/29/17 2:28 AM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> On 29/08/2017 5:39 AM, coleen.phillimore at oracle.com wrote:
>>>>
>>>>
>>>> On 8/28/17 3:38 PM, coleen.phillimore at oracle.com wrote:
>>>>>
>>>>> Here is the third webrev with the names of pd_set and set_pd_set 
>>>>> renamed to pd_set_acquire and release_set_pd_set.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8164207.03/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8164207
>>>
>>> This API should also be renamed:
>>>
>>> !   ProtectionDomainEntry* pd_set() const            { return 
>>> _inner.pd_set_acquire(); }
>>> !   void set_pd_set(ProtectionDomainEntry* new_head) { 
>>> _inner.release_set_pd_set(new_head); }
>>>
>>> These are the ones that need to give visibility to the fact we're 
>>> accessing things lock-free (if indeed we are).
>>>
>>> More below ...
>>>
>>>>> On 8/28/17 8:07 AM, coleen.phillimore at oracle.com wrote:
>>>>>> On 8/28/17 12:25 AM, David Holmes wrote:
>>>>>>> Hi Coleen,
>>>>>>>
>>>>>>> On 25/08/2017 11:26 PM, coleen.phillimore at oracle.com wrote:
>>>>>>>>
>>>>>>>> Thank you Zhengyu for noticing this change was wrong, and 
>>>>>>>> Christian for the idea.   New webrev:
>>>>>>>>
>>>>>>>> open webrev at 
>>>>>>>> http://cr.openjdk.java.net/~coleenp/8164207.02/webrev
>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8164207
>>>>>>>
>>>>>>> The idea of a load-acquire accessor and release_store-setter is 
>>>>>>> fine in principal, but it seems to me that we now use these 
>>>>>>> everywhere, even if we may not need them because there is no 
>>>>>>> concurrent/lock-free access. Overall I find it very difficult to 
>>>>>>> determine what the concurrent access patterns are for a 
>>>>>>> Dictionary versus a DictionaryEntry, and which paths are in fact 
>>>>>>> lock and/or safepoint free, and may be racing with locked or 
>>>>>>> safepointed code. ??
>>>>>>
>>>>>> That's exactly the point of making them accessors.  So one 
>>>>>> doesn't have to visit each individual call site and spend time 
>>>>>> answering the question for each case.  And probably getting it 
>>>>>> wrong.   The performance delta for these accesses is minimal 
>>>>>> since it's only getting the head of the list, not each element.
>>>>>>
>>>>>> Then it's also future proof so that if a lock is removed, then we 
>>>>>> don't miss one of the accessors at a later time. Note that 
>>>>>> observing bugs caused by this is very difficult to do, and can 
>>>>>> only be done by inspection.   That's why I erred on the side of 
>>>>>> safety and consistency.
>>>
>>> Sorry, it may sound strange to say that I don't agree with "erring 
>>> on the side of safety and consistency" but I do not agree with just 
>>> using acquire/release semantics everywhere just in case! If we don't 
>>> know the lock-free paths then how can we possibly know things are 
>>> correct. The whole point of these accessors is to make it obvious 
>>> where the lock-free accesses are.
>>>
>>>>>>>
>>>>>>> That aside I don't understand why you added a level of 
>>>>>>> indirection with the ProtectionDomainSet class?
>>>>>>
>>>>>> Only the code is a level of indirection not the access. That is 
>>>>>> to avoid what I said above.  See Christian's and Zhengyu's comments.
>>>
>>> Okay - I see what you did but I would not expect to have to protect 
>>> _pd_set from direct use within its own class - anyone messing with 
>>> that class should be aware of the need to use the accessors. Though 
>>> I suppose this encapsulation is little different to defining the 
>>> field as some kind of "Atomic" type rather than a "raw" type.
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>>>>>
>>>>>>> Also we have been trying to include release/acquire in the names 
>>>>>>> of such accessors so that it is clear when we are relying on 
>>>>>>> memory ordering properties ie. pd_set_acquire and 
>>>>>>> release_set_pd_set
>>>>>>>
>>>>>>
>>>>>> I will change the names of these functions.
>>>>>>
>>>>>> thanks,
>>>>>> Coleen
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> I reran parallel class loading tests and jck testing is in 
>>>>>>>> progress, but order access requires inspection.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/24/17 5:11 PM, coleen.phillimore at oracle.com wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/24/17 5:00 PM, Christian Thalinger wrote:
>>>>>>>>>>> On Aug 24, 2017, at 10:54 AM, coleen.phillimore at oracle.com 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 8/24/17 4:07 PM, Zhengyu Gu wrote:
>>>>>>>>>>>> Hi Coleen,
>>>>>>>>>>>>
>>>>>>>>>>>> There are two instances probably overlooked?
>>>>>>>>>>>>
>>>>>>>>>>>> dictionary.cpp #103 and #124
>>>>>>>>>>>>
>>>>>>>>>>>>     for (ProtectionDomainEntry* current = _pd_set;
>>>>>>>>>>>> =>
>>>>>>>>>>>>     for (ProtectionDomainEntry* current = pd_set();
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Oh yeah, you're right.  That's embarrasing. I'll fix and 
>>>>>>>>>>> retest.
>>>>>>>>>> Which also shows that there is a potential for future 
>>>>>>>>>> mistakes. Can we isolate the field better so it’s only 
>>>>>>>>>> accessible via setter and getter?
>>>>>>>>>
>>>>>>>>> Yes, great idea.
>>>>>>>>> Coleen
>>>>>>>>>
>>>>>>>>>>> Thank you!!
>>>>>>>>>>> Coleen
>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/24/2017 02:28 PM, coleen.phillimore at oracle.com wrote:
>>>>>>>>>>>>> Summary: Use load_acquire for accessing 
>>>>>>>>>>>>> DictionaryEntry::_pd_set since it's accessed outside the 
>>>>>>>>>>>>> SystemDictionary_lock
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ran parallel class loading tests that we have as well as 
>>>>>>>>>>>>> tier1 tests. See bug for details.
>>>>>>>>>>>>>
>>>>>>>>>>>>> open webrev at 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8164207.01/webrev
>>>>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8164207
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Coleen
>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>



More information about the hotspot-runtime-dev mailing list