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:03:12 GMT
Aleksey Ignatenko wrote:
> Hi, Robin.
> I do really like this proposed idea of marking VTables from objects via
> additional word field in VTable.
> 
> But I have one question about detecting reachability of the classloaders
> ("sweep the vtables and check the reachability of the classloaders").
> Possibly I missed something, but here is my view of the current model of
> drlvm: all j.l.Classes and j.l.Classloaders are enumerated as strong roots
> (strong references). Therefore we meet situation when all j.l.Classes and
> j.l.Classloaders are always reachable (marked). And no sweep will help to
> detect classloaders reachability.
> I see the single way to distinguish if j.l.Classloader or j.l.Class was
> marked not by strong root from VM but by some reference from heap - is
> to write unique object value into VTable. Then we can detect if some
> jlClasloader was marked from rootset (strong root from VM) or from some 
> live
> object.

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

Then for any classloader where (!reachable), free its native resources 
and remove its strong root.  The java resources will be freed at next GC.

> I also want to say that 1-st proposed design from me assumed addtional
> mark&scan phase without enumeration of jlClasses and jlClassloaders to be
> able to detect their reachability.

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.

In terms of runtime cost, I would expect an auxiliary scan of this type 
to be equivalent in cost to a full-heap GC.  The other solution costs 
~1% of all GCs.  As a "back of a matchbox" calculation, if this is run 
less than every 100 (full heap) GCs, then the auxiliary trace is a win, 
if not, my other solution is a win.

> Could you, please, clarify this moment.
> Thanks, Aleksey.

Hope this answers your questions
cheers,
Robin

> 
> On 11/3/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>>
>> On 11/2/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> >
>> > >Robin, thanks for all the clarifications. Now it seems clear to me 
>> >and
>> > >I am convinced by this proposal. :-)
>>
>>
>> Yes, this proposal is the simplest and has the least perf impact. Thanks
>> Robin.
>>
>>
> 


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

Mime
View raw message