RFR: 8293337: Store method handle intrinsics in AOT cache [v9]

[Dan Heidinga]

On Tue, 15 Oct 2024 23:56:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.cpp line 2097:
>> 
>>> 2095:     }
>>> 2096: 
>>> 2097:     MutexLocker ml(InvokeMethodIntrinsicTable_lock);
>> 
>> Should we take this lock once outside the loop and hold it for the duration rather than taking it just again and again before each add operation?
>
> The lock cannot be held while calling `AdapterHandlerLibrary::create_native_wrapper()` -- a few lines above. Otherwise  you'd see an error like
> 
>> assert(false) failed: Attempting to acquire lock AdapterHandlerLibrary_lock/safepoint out of order with lock InvokeMethodIntrinsicTable_lock/safepoint -- possible deadlock
> 
> You can see the same pattern with the existing code
> 
> https://github.com/openjdk/jdk/blob/b9cabbecdac27ae8b93df88660a4a0f3f60e6828/src/hotspot/share/classfile/systemDictionary.cpp#L2008-L2022
> 
> Most of the work is done inside `AdapterHandlerLibrary::create_native_wrapper()`, which generates native code. Also, this loop happens while the JVM is still in single-threaded mode, so there's no contention on the lock. The cost of taking this lock is negligible.

Thanks for confirming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20959#discussion_r1803354428