On Tue, 15 Feb 2022 09:48:21 GMT, Maurizio Cimadamore <[email protected]>
wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the coupling of RawNativeLibraries with JNI library loading
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 427:
>
>> 425: new ConcurrentHashMap<>();
>> 426:
>> 427: static void acquireNativeLibraryLock(String libraryName) {
>
> Note sure about these two routines. Should they be shared? Should we have two
> locks, one for JNI, one for raw? Of course, as is the code looks fine - but I
> wonder if a single lock isn't overly strict.
I initially planned to come back to this but I obviously forgot.
This does not need the per-library locking for JNI library which avoids the
deadlock due to the class and library loading scenarios involving JNI_OnLoad,
class initialization, and `Sytem::loadLibrary`. I now removed the locking
entirely as it uses the concurrent hash map to register/unregister the loaded
libraries. Much simplified.
> src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line
> 107:
>
>> 105: * {@link System#mapLibraryName} can be used to convert a name to
>> 106: * a platform-specific pathname:
>> 107: * {@snipplet
>
> Suggestion:
>
> * {@snippet
Fixed.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7435
