RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v3]
Maurizio Cimadamore
mcimadamore at openjdk.java.net
Tue Feb 15 09:52:18 UTC 2022
On Tue, 15 Feb 2022 02:17:00 GMT, Mandy Chung <mchung at openjdk.org> 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
More information about the core-libs-dev
mailing list