RFR: 8259242: Remove ProtectionDomainSet_lock [v3]

Coleen Phillimore coleenp at openjdk.java.net
Fri Apr 9 11:34:20 UTC 2021


On Fri, 9 Apr 2021 02:17:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make ProtectionDomainEntry delete list global and set a threshold for deletions before handshaking. Fix if to when.
>
> Hi Coleen,
> 
> Thanks for the additional explanations about the synchronization protocol that is being used. The use of the global handshake with the OM deletion had not really registered with me as a general technique that we would employ for safe-memory-reclamation. (I'm not sure if I find it cool or scary! :) )
> 
> So to summarise the protocol:
> - the pd_set can only be set and appended to when the lock is held
> - traversal of a pd_set is lock-free
> - removal from a pd_set is a two phase process:
> -   1. Under the lock move the entry to the global delete list
> -   2. When appropriate the serviceThread will process the delete list, by first handshaking all threads, and then iterating through and deleting the entries
> 
> We know an entry cannot be in-use when deleted because that implies a traversal is in progress, but if a traversal is in progress then the handshake cannot have happened.
> 
> Is that correct?
> 
> I would like to see this high-level description as a block comment somewhere for clarity, as the individual pieces of code seem spread around and it is not easy (for me) to see the connections when just reading the code.
> 
> Thanks,
> David

Hi David,  Yes you have the design correct.  It's used for ObjectMonitors, nmethod unloading, implicitly class unloading with ZGC, and now this.   The concurrent hashtable uses the globalCounter mechanism, which I briefly considered but it would have required more surgery to the code and would slightly affect read times, and that mechanism is more complicated imo.  I could have done something with a lock bit/refcount for readers but that's more error prone and harder to get right. There's a new lockFreeQueue.hpp implementation but this wasn't a queue.
Maybe this should be generalized to be lockFreeList sometime.

I put a block comment before Dictionary::contains_protection_domain, the lock free reader with the NSV which describes the protocol.  Hopefully this is clear.  Thanks!

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

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


More information about the hotspot-dev mailing list