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