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

[Coleen Phillimore]

On Wed, 7 Apr 2021 12:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> 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.

The reader thread could be using the linked list and have just loaded -> next, while the deleting thread also has loaded -> next, deciding it's unused and calling delete on it.  The reader is then swapped back in the process and looks at the _pd_cache field which was deleted or the _next field which is will point to the delete pattern.
When we call 'delete' on a node in this list, we have to make sure that nothing is reading it.

The concurrent hashtable uses globalCounter for this situation.  Many of our lock free data structures delete entries in safepoints (like dictionaries).   This pd_set list does the same as the ObjectMonitor code.

The handshake is rare as I said in the comments.  The protection domain is generally associated with the klass in the initiating loader, which stays alive while this class is alive.

-------------

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