From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9756 invoked by alias); 5 Nov 2008 10:45:12 -0000 Received: (qmail 9709 invoked by uid 22791); 5 Nov 2008 10:45:11 -0000 X-Spam-Check-By: sourceware.org Received: from web28503.mail.ukl.yahoo.com (HELO web28503.mail.ukl.yahoo.com) (87.248.110.182) by sourceware.org (qpsmtpd/0.31) with SMTP; Wed, 05 Nov 2008 10:44:12 +0000 Received: (qmail 21556 invoked by uid 60001); 5 Nov 2008 10:44:09 -0000 X-YMail-OSG: W4Yz_uEVM1l.OWcoOLbi_opdnxI6a9ebT1c13ULzmhdqmfTkuMCjr0lVT1Eg8EYxb2oEJhYZ2eIgurMOpCMoL0GGKQAXh8G3aKlHJuR1CMjmYzoFaDt4vwdEmvgw9zLYza.4KIKk0CNyrHkQUsF71zyOvHycI4mssGG9MMZWWf6w_gw- Received: from [205.167.7.18] by web28503.mail.ukl.yahoo.com via HTTP; Wed, 05 Nov 2008 10:44:09 GMT X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 Date: Wed, 05 Nov 2008 10:45:00 -0000 From: =?iso-8859-1?Q?Sylvain_Mari=E9?= Subject: Re: [GCJ-core] dynamically unloading native libraries To: java@gcc.gnu.org, mark@klomp.org Cc: aph@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <486895.21159.qm@web28503.mail.ukl.yahoo.com> Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg00021.txt.bz2 Hi Mark, Thank you for putting the topic back on the table, > We seem to never even call JNI_OnUnload on the jni libraries. That's exactly my point - and also even libraries that do not contain JNI a= t all (simple .so without any relation to java - I know it is not a very useful c= ase but it is very simple to test with a dummy .so). But the root cause of the problem is a bit more complex:=20 a) As you mentioned, ClassLoaders don't unload unused native libraries when= they are finalized. but also b) ClassLoaders don't even seem to be finalized when they are not used any = more. (no alive instances, etc.) So even correcting a) would not help, we should first try to understand why= =20 ClassLoaders are never gc'ed. Once again, this seems to be done in openJDK (at least item a, and maybe th= e b): -------------------ClassLoader.java------------------------------------ protected void finalize() { synchronized (loadedLibraryNames) { if (fromClass.getClassLoader() !=3D null && handle !=3D 0) { /* remove the native library name */ int size =3D loadedLibraryNames.size(); for (int i =3D 0; i < size; i++) { if (name.equals(loadedLibraryNames.elementAt(i))) { loadedLibraryNames.removeElementAt(i); break; } } /* unload the library. */ ClassLoader.nativeLibraryContext.push(this); try { unload(); } finally { ClassLoader.nativeLibraryContext.pop(); } } } } ---------------------------------------------------------------------------= ------- Kind regards, Sylvain > ----- Message de Mark Wielaard sur Sun, 02 Nov 2008 > 18:43:12 +0100 ----- >=20 > Pour: >=20 > Andrew Haley >=20 > cc: >=20 > Sylvain Mari=E9 , java@gcc.gnu.org >=20 > Objet: >=20 > Re: [GCJ-core] dynamically unloading native libraries >=20 > Hi, >=20 > Responding to a pretty old email that I only saw just now for some > reason. >=20 > On Tue, 2008-10-07 at 13:41 +0100, Andrew Haley wrote: > > Sylvain Mari=E9 wrote: > > > I am working on a project involving GCJ on an embedded Linux busybox.= =20 > > > We are particularly fond of the ability of GCJ to use java in=20 > "compiled mode". > > >=20 > > > In order to be able to use both native code (.so), compiled java > (.so) and bytecode java=20 > > > (.jar, .class) together with a module loading system, we are=20 > running some tests to validate=20 > > > that dynamic code loading/unloading works fine. > > >=20 > > > Strangely enough this does not work on GCJ, whereas it works=20 > fine on sun's jvm (a native=20 > > > library is fully unloaded once its classloader is garbaged out). > > >=20 > > > see also :=20 > > >> openJDK, in jdk/src/share/classes/java/lang/ClassLoader.java:=20 > finalize method unloads native libraries > > >=20 > > > Is this feature planned to be inetgrated in next versions of therunti= me ? > >=20 > > No. While this could be done, it would be quite tricky. > >=20 > > 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. >=20 > 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. >=20 > Cheers, >=20 > Mark >=20