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

[Ioi Lam]

On Mon, 14 Oct 2024 15:09:19 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - @coleenp comments
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - @vnkozlov comment - added NOT_CDS_RETURN
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/65d49dcc...84777aa4
>
> 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.

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

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