This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: classloading from so
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'tromey at redhat dot com'" <tromey at redhat dot com>, Lars Andersen <lars at rimfaxe dot com>
- Cc: java at gcc dot gnu dot org
- Date: Tue, 24 Sep 2002 14:28:18 -0700
- Subject: RE: classloading from so
> From: Tom Tromey [mailto:tromey@redhat.com]
> >>>>> "Lars" == Lars Andersen <lars@rimfaxe.com> writes:
>
> Lars> What if an app loaded that class, then lib-org-pack.so is
> Lars> recompiled. If the app should issue another class.forName,
> Lars> would it load the newly compiled .so ? Or would the app have to
> Lars> be restarted?
>
> The app would have to be restarted. Currently we never unload shared
> libraries.
>
> It appears if you use the SharedLibLoader, instead of the built-in
> one, then you can get class unloading. I have never tried it, but I
> do note that SharedLibLoader.finalize() calls dlclose(). Of course,
> for this to work, the SharedLibLoader and all its classes must be
> collected.
Hopefully the class loader is referenced from a static variable in the loaded library? Thus this can never happen because the garbage collector views the library static data as roots and would thus never collect the class loader?
I say "hopefully" because I'm pretty sure we have no mechanism to test whether a static method of some class is still on a call stack somewhere. Thus if we could unload such classes, we could probably unload them while the code is still running, which would be a bug, not to mention security hole.
Hans