RE: classloading from so

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

> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> > 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.
> 
> What if class references were passed as first argument to a 
> static method?
> I realize that would be a major change to the API, but does 
> it solve the
> problem?  (It would help other things, like initialization 
> tests.  Static
> members could be loaded with offset addressing, etc.)
> 
You would still have to tell the back end that the argument is live until function exit.  That tends to be automatic on X86 since arguments always go on the memory stack, but not on most other architectures.

The more I think about, I believe that static member accesses are essentially the same issue.  You really need to scan stacks for pointers to the mapped region for the library, both text and data, and not call dlclose until those go away.  I don't think it would be very hard to teach the GC to do that, but the interface to do so isn't currently there.

The rest of this is probably more difficult.  In particular, it seems to me that "nonpermanent" classes would always need heap allocated vtables, since we can't otherwise even track when the last instance of a class disappears.  How does this interact with the binary compatibility discussion?

Another issue:  The dlclose shouldn't ever be done by a finalizer.  As is pointed out in the JLS, Finalization can happen too early, since other finalizers may still rely on the class.  And we're carefully following the Java rules about unordered finalization, thus breaking uses like this. 

Hans