RE: classloading from so

["Boehm, Hans" <hans_boehm at hp dot com>]

> From: Tom Tromey [mailto:tromey@redhat.com]
> ...
> For a class loaded by SharedLibLoader we could register the `loader'
> field as a disappearing link.  Would that work correctly?
I'm not sure I understand the full picture here.  Is there a heap object representing the class which becomes inaccessible when a class is no longer needed?  I didn't think there was such a thing.  So I'm not sure there would be any way for the collector to tell when this should disappear.  (This assumes it actually gets set.  I think Jeff concluded it doesn't.)  
> 
> Hans> I say "hopefully" because I'm pretty sure we have no mechanism
> Hans> to test whether a static method of some class is still on a call
> Hans> stack somewhere.  Thus if we could unload such classes, we could
> Hans> probably unload them while the code is still running, which
> Hans> would be a bug, not to mention security hole.
> 
> Also a good point.  There has to be a way to fix this though.
I think it's hard, though not impossible.  AFAICT, you actually need to scan stacks for code addresses, map those code addresses to classes, and make sure those classes are retained.

There are other issues with all of this:

1) dlopen should really go through its GC wrapper.  Hopefully it does.  Dlclose needs a corresponding wrapper which hasn't yet been written.  Once upon a time this seemed hard, though it now looks to me like it would suffice to basically clone the dlopen wrapper.

2) (More serious.)  Consider the case in which the last thing I do with any class loaded by a particular class loader is to assign something to a static member of such a class.  There is no reason to believe that the class or loader still appear accessible to the garbage collector as I'm about to execute the store instruction.  Only the address of the static member is needed, and everything else is dead.  Thus I can garbage collect the classloader at this point.  But unmapping the memory for the static member is unsafe.  This is closely related to some similar issues with finalization.

Dlclose with multiple threads is tricky ...

Hans