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:58:05 GMT
Aleksey Ignatenko wrote:
> Robin.
> 
>> 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.
> 
> 
> If you have weak reference to j.l.Classloader - GC will collect it (with 
> all
> appropriate jlClasses) as soon as there are no references to
> j.l.Classloaderand appropriate classes. But there is possible
> situation when there are some
> live objects of that classes and no references to jlClassloader and
> jlClasses. This will lead to unpredictable consequences (crash, etc).
> 
> 
> 
> I want to remind that there 3 mandatory conditions of class unloading:
> 
> 1. j.l.Classloader instance is unreachable.
> 
> 2. Appropriate j.l.Class instances are unreachable.
> 
> 3. No object of any class loaded by appropriate class loader exists.

Let me repeat.  I offer an efficient solution to (3).  I don't purport 
to have a solution to (1) and (2).

Regards,
Robin

> 
> 
> Aleksey.
> 
> 
> On 11/8/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>>
>> 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
>>
> 


-- 
Robin Garner
Dept. of Computer Science
Australian National University

Mime
View raw message