Etienne,
I read section 3.2.3 (Class-Loader-Specific Memory) of gagnon-phd.pdf.
Please tell me if the following is a correct interpretation. You create
a new memory manager that is uniquely associated with each new class
loader. All the C data structures associated with a class loader (classes,
vtables, etc) are "malloc()ed" out of the associated memory manager. When
the class loader becomes unreachable, then its associated memory manager is
deallocated which automatically frees all the associated C structs (classes,
vtables, etc.)
Everyone,
Does it make sense to try to implement Etienne's scheme?
On 10/30/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
>>> 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
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
--
Weldon Washburn
Intel Enterprise Solutions Software Division
