This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]