RFR: 8290370: Convert SymbolPropertyTable to ResourceHashtable [v3]

[Coleen Phillimore]

On Mon, 1 Aug 2022 22:48:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Justin Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespaces
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1669:
> 
>> 1667:     f(method);
>> 1668:   };
>> 1669:   _invoke_method_intrinsic_table.iterate_all(doit);
> 
> Hmm, this is problematic. The modification of the old `invoke_method_table()` was protected by `SystemDictionary_lock`, but `invoke_method_table()->methods_do(f)` was not. Maybe it worked because `invoke_method_table()` could be read lock-free?
> 
> The trouble is that ResourceHashtable is not lock free. However, we cannot hold `SystemDictionary_lock` here because it might introduce a deadlock with the `f` callback.
> 
> I am not sure what can be done here.

I'm pretty sure Justin can take the InvokeMethodTable_lock around the methods_do() call, since this lock is the highest ranked lock.  He'll have to reduce the scope of the ClassLoaderDataGraph_lock above it.

> src/hotspot/share/runtime/mutexLocker.cpp line 358:
> 
>> 356:   defl(Heap_lock                   , PaddedMonitor, MultiArray_lock);
>> 357:   defl(Compile_lock                , PaddedMutex  , MethodCompileQueue_lock);
>> 358:   defl(AdapterHandlerLibrary_lock  , PaddedMutex  , InvokeMethodTable_lock);
> 
> The changes of AdapterHandlerLibrary_lock seem to be unrelated to this issue and should be reverted.

With the change to hold InvokeMethodTable_lock around creating the Method*, AdapterHandlerLibrary_lock was taken out while holding InvokeMethodTable_lock.

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

PR: https://git.openjdk.org/jdk/pull/9495