harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm] Class unloading support - tested one approach
Date Wed, 08 Nov 2006 10:28:43 GMT
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 

> 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.


Robin Garner
Dept. of Computer Science
Australian National University

View raw message