This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: classloading from so
- From: Jeff Sturm <jsturm at one-point dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'tromey at redhat dot com'" <tromey at redhat dot com>, Lars Andersen <lars at rimfaxe dot com>, <java at gcc dot gnu dot org>
- Date: Wed, 25 Sep 2002 17:45:33 -0400 (EDT)
- Subject: RE: classloading from so
On Wed, 25 Sep 2002, Boehm, Hans wrote:
> > 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?
Not for compiled classes AFAIK.
> 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.)
I created libgcj/8027 for this, along with a test case that actually
crashes upon dlclose.
> 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.)
Jeff