RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out

David Holmes david.holmes at oracle.com
Thu Apr 8 09:52:16 UTC 2021


On 7/04/2021 10:05 pm, Coleen Phillimore wrote:
> On Wed, 7 Apr 2021 04:55:35 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock.  This lock is a singleton that's taken for every dictionary entry.
>>>
>>> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate.
>>>
>>> Tested with tiers 1-3.  There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java.
>>
>> Hi Coleen,
>>
>> Can you explain the synchronization protocol you are using here please - I don't understand how the handshake fits into it ??
>>
>> Further comments below.
>>
>> Thanks,
>> David
> 
> The lock-free algorithm is based on the one for object monitors, except that adding and deleting entries is done with the SystemDictionary_lock held, reading entries is done with a (now) Atomic load acquires etc with no safepoint polls, and deleting the entries is done by saving the entries off to the side, until a handshake is reached, meaning none of the readers are reading the old version of the list.

I really don't see why we need to use handshakes here. The writers use a 
lock, and use release_stores. The readers use load_acquire. Our normal 
lock-free data structures don't need handshakes to be involved, so sorry 
but I'm not getting it.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3362
> 


More information about the hotspot-dev mailing list