JDK8: Unloading native JNI library
david.holmes at oracle.com
Fri Aug 25 02:33:20 UTC 2017
And what is the name of the library?
On 25/08/2017 12:18 PM, David Holmes wrote:
> Hi Vemund,
> What OS do you see this on? Are you able to test different OS?
> On 24/08/2017 10:37 PM, Vemund Ostgaard wrote:
>> I am struggling with a problem related to unloading (and reloading) a
>> native JNI library that has been loaded with System.load(). I have
>> been referred to this mailing list as the right place to ask, so
>> seeking your advice on the issue.
>> My goal was to load a JNI library from a JVM process and be able to
>> reload an updated copy of the same library later without restarting
>> the JVM. The library might be loaded from the exact same path as
>> before or from a different path.
>> The testing I have done (more details below) indicates to me that the
>> first JNI library I load with System.load() does not get unloaded
>> completely when its loading classloader is garbage collected,
>> subsequent attempts to load a library from the same path indicates
>> that the native library kept the state it had from the first loaded copy.
>> Surprisingly though, any other copy of the native library that is
>> loaded from other file system locations than the first path are
>> apparently unloaded when their loading classloader is garbage
>> collected, and subsequent attempts to load from those paths indicate
>> that those libraries do not keep their state.
>> So, I am curious whether there is something special about the first
>> time System.load() is used from application code in a new JVM, and
>> whether there is some way I can avoid that behavior.
>> Details about my testing:
>> I have added these methods to my native JNI library:
>> JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *jvm, void *reserved)
>> printf("JNI_OnLoad called: %d\n", counter);
>> return JNI_VERSION_1_4;
>> JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *jvm, void *reserved)
>> printf( "JNI_OnUnload called: %d\n", counter);
>> The counter is a global variable in the same file, and it is
>> initialized to 0. The plan was to see if the counter was initialized
>> to 0 again after the library is unloaded and loaded again, and also to
>> see that these methods were called at all. I also recompiled the
>> native library in two other versions with the counter initialized to
>> 100 and 200 respectively, to be able to tell the difference between
>> different copies of the library being loaded/unloaded.
>> I wrote a small java class that calls System.load() to load my native
>> JNI library, and a small custom classloader that extends URL
>> classloader. To both of these classes I added overrides for finalize()
>> just to see it being called and printing out a unique ID to know what
>> copy of each class was being finalized.
>> The third Java class is just a main() method that calls a test()
>> method with the test logic using the other two classes to test loading
>> and unloading of the native library. When the test() method returns to
>> the main() method, the classloader object goes out of scope and I call
>> System.gc() a few times to get everything garbage collected. The
>> test() method also returns a WeakReference() to the classloader object
>> so I can call WeakReference.get() before and after the System.gc()
>> calls to verify that this becomes null. I interpret the WeakReference
>> becoming null as a sign that my classloader is getting garbage collected.
>> My testing shows that in all cases:
>> - JNI_OnLoad() and JNI_OnUnload() gets called as expected
>> - The finalizer() methods for my two classes are called as expected
>> - The WeakReference.get() for my custom classloader returns null after
>> a few System.gc() calls and sleeping a couple seconds total.
>> As already mentioned, the first JNI library loaded keeps its state,
>> the counter printed from JNI_OnLoad() and JNI_OnUnload() keeps
>> increasing for every repeated load+unload from that file location,
>> while for all other libraries loaded from other file locations, the
>> state is apparently reset. This holds true also if using multiple
>> custom classloaders or identical copies of the JNI library in
>> different locations. The key factor seems to only be loading from the
>> same file location as used the first time.
>> I can't see that my code behaves any different for the multiple times
>> I try to load and unload the JNI libraries, so I am wondering if there
>> is some JNI bug or known behavior that explains what I see?
>> Thank you,
More information about the core-libs-dev