harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm] Class unloading support - tested one approach
Date Wed, 08 Nov 2006 10:10:54 GMT

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.

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

Pavel Pervov,
Intel Enterprise Solutions Software Division

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