Re: [GCJ-core] dynamically unloading native libraries

[Mark Wielaard <mark at klomp dot org>]

Hi,

Responding to a pretty old email that I only saw just now for some
reason.

On Tue, 2008-10-07 at 13:41 +0100, Andrew Haley wrote:
> Sylvain Marià wrote:
> > I am working on a project involving GCJ on an embedded Linux busybox. 
> > We are particularly fond of the ability of GCJ to use java in "compiled mode".
> > 
> > In order to be able to use both native code (.so), compiled java (.so) and bytecode java 
> > (.jar, .class) together with a module loading system, we are running some tests to validate 
> > that dynamic code loading/unloading works fine.
> > 
> > Strangely enough this does not work on GCJ, whereas it works fine on sun's jvm (a native 
> > library is fully unloaded once its classloader is garbaged out).
> > 
> > see also : 
> >> openJDK, in jdk/src/share/classes/java/lang/ClassLoader.java: finalize method unloads native libraries
> > 
> > Is this feature planned to be inetgrated in next versions of the runtime ?
> 
> No.  While this could be done, it would be quite tricky.
> 
> The core problem is that pointers to code (e.g. return addresses in
> the stack) aren't recognized by the garbage collector as pointers to
> the corresponding classes.  You'd have to teach the collector to
> convert code addresses to classes, and then garbage collect the
> classes.

But couldn't/shouldn't we do it for JNI native code that was loaded
through the ClassLoader when that ClassLoader is garbage collected?
I believe that is what Sylvain is testing?
We seem to never even call JNI_OnUnload on the jni libraries. Which
seems to suggest we never ever try to unload them even when they are no
longer needed.

Cheers,

Mark