Pavel Pervov wrote:
Robin,
The kind of model I had in mind was along the lines of:
- VM maintains a linked list (or other collection type) of the currently
loaded classloaders, each of which in turn maintains the collection of
classes loaded by that type. The sweep of classloaders goes something
like:
for (ClassLoader cl : classLoaders)
for (Class c : cl.classes)
cl.reachable |= c.vtable.reachable
This is not enough. There are may be live j/l/Class'es and
j/l/Classloader's
in the heap. Even though no objects of any classes loaded by a particual
class loader are available in the heap, if we have live reference to
j/l/ClassLoader itself, it just can't be unloaded.
OK, well how about keeping a weak reference to the j.l.ClassLoader
object instead of a strong one. When the reference becomes (strong)ly
unreachable, invoke the class-unloading phase.
To me the key issue from a performance POV is the reachability of
classes from objects in the heap. I don't pretend to have an answer to
the other questions---the performance critical one is the one I have
addressed, and I accept there may be many solutions to this part of the
question.
I believe that a separate heap trace pass, different from the standard
GC, that visited vtables and reachable resources from there would also
be a viable solution. As mentioned in an earlier post, writing this in
MMTk (where a heap trace operation is a class that you can easily
subtype to do this) would be easy.
One of the advantages of my other proposal is that it can be implemented
in the VM independent of the GC to some extent. This additional
mark/scan phase may or may not be easy to implement, depending on the
structure of DRLVM GCs, which is something I haven't explored.
DRLVM may work with (potentially) any number of GCs. Designing class
unloading the way, which would require mark&scan cooperation from GC, is
not
generally a good idea (from my HPOV).
That's what I gathered. hence my proposal.
cheers
--
Robin Garner
Dept. of Computer Science
Australian National University
