harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm] Class unloading support - tested one approach
Date Wed, 08 Nov 2006 10:50:38 GMT

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


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message