[GCJ-core] dynamically unloading native libraries
Andrew Haley
aph@redhat.com
Mon Nov 3 10:46:00 GMT 2008
Mark Wielaard wrote:
>> 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?
We could, but that isn't the subject of the question. At least I didn't
think it was.
The answer to the original poster is that yes, it can be done, but it
would require some work.
> I believe that is what Sylvain is testing?
As far as I could see the question was about unloading of gcj-compiled
java code. If the question is about JNI libraries, then yes, it still
requires some work but it should be easier.
> 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.
Sure, but making sure that in every case we can track all live references to
native code is not trivial.
Andrew.
More information about the Java
mailing list