harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject Re: [drlvm] Class unloading support
Date Mon, 30 Oct 2006 13:00:25 GMT
>>> If I get it right, in case of automagic unloading, GC does all the job
>>> without a knowledge whether it collects a class, a classloader or
>>> whatever else.
>>> Perhaps I'm missing something, but to provide a callback on class
>>> unloading, the GC must know the semantic of the object being collected.

Am I wrong, or does this proposition imply collecting classes
independently from their class loader?  If this is the case, I have to
say that I disagree with the proposed approach.

The JVM spec says quite clearly:

 2.17.8 Unloading of Classes and Interfaces

 A class or interface may be unloaded if and only if its class loader is
 unreachable. The bootstrap class loader is always reachable; as a
 result, system classes may never be unloaded.

Just think about it.  One could take an instance "o" of a class C loaded
by L, call it (C,L), and call o.getClass().hashcode().  Store this
integer some where.  Then, "o" could die, and maybe (C,L) unloaded while
L is still reachable.  As L is still reachable, some code could do a
L.findClass("C").hashcode().  This will likely result in a different
hashcode, in full breach of the both the VM and API specifications.

In a related note, for memory management I highly encourage Drlvm to
look at Chapter 3 of http://sablevm.org/people/egagnon/gagnon-phd.pdf
that exposes a simple, yet very effective approach for managing
class-loader related memory (i.e. memory used to store internal class
data, vtables, jitted code) so that it can all be freed efficiently at
class-loader unloading time.


Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

View raw message