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

Coleen Phillimore coleenp at openjdk.java.net
Wed Apr 7 11:53:11 UTC 2021


On Wed, 7 Apr 2021 04:38:24 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.
>
> src/hotspot/share/classfile/dictionary.cpp line 422:
> 
>> 420: void Dictionary::clean_cached_protection_domains(GrowableArray<ProtectionDomainEntry*>* delete_list) {
>> 421:   assert(Thread::current()->is_Java_thread(), "only called by JavaThread");
>> 422:   assert_locked_or_safepoint(SystemDictionary_lock);
> 
> If the current thread must be a JavaThread then we cannot be at a safepoint and so the second assert can just check the lock is held.

sure.

> src/hotspot/share/classfile/dictionary.hpp line 145:
> 
>> 143: 
>> 144:   ProtectionDomainEntry* pd_set() const            { return Atomic::load(&_pd_set); }
>> 145:   void set_pd_set(ProtectionDomainEntry* entry)    { Atomic::store(&_pd_set, entry); }
> 
> These probably need to be load_acquire and release_store, so that a lock-free traversal can proceed correctly with a locked addition/removal. With suitable name changes for the methods.

I forgot that the method names have to match the implementation details. Thanks I didn't know whether they needed acquire etc.

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

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


More information about the hotspot-dev mailing list