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 <[EMAIL PROTECTED]> wrote:
On 11/2/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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
