RFR: 8290370: Convert SymbolPropertyTable to ResourceHashtable [v3]

[Ioi Lam]

On Mon, 1 Aug 2022 17:54:58 GMT, Justin Gu <duke at openjdk.org> wrote:

>> Converting the invoke_method_table into two tables, invoke_method_instrinsic_table and invoke_method_type_table
>
> Justin Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespaces

Changes requested by iklam (Reviewer).

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.

src/hotspot/share/classfile/systemDictionary.cpp line 2054:

> 2052:   signature->make_permanent(); // The signature is never unloaded.
> 2053:   _invoke_method_intrinsic_table.put(key, m());
> 2054:   assert(m() != NULL, "");

This assert seems odd. It seems to correspond to the old assert `spe->method() != NULL`, but that one says "we must have a hashtable entry that contains a non-null method". In the new code, we don't deal with hashtable entries directly anymore, so this assert can be removed.

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.

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

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