On Tue, 15 Feb 2022 02:17:00 GMT, Mandy Chung <[email protected]> wrote:
>> This patch removes the restriction in the raw library loading mechanism that
>> does not allow mix-n-match of loading a library as a JNI library and as a
>> raw library.
>>
>> The raw library loading mechanism is designed for panama to load native
>> library essentially equivalent to dlopen/dlclose calls independent of JNI
>> library loading. If a native library is loaded as a JNI library and a raw
>> library, it will get different NativeLibrary instances. When a class loader
>> is being unloaded, JNI_Unload will be invoked but the native library may not
>> be unloaded until NativeLibrary::unload is explicitly called for the raw
>> library.
>
> 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
Looks - good, I like the way this patch makes a cleaner distinction between
JNI-like and more dlopen-like 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.
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
-------------
Marked as reviewed by mcimadamore (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7435
