harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [drlvm][sablevm] Desing of Class Unloading Support
Date Tue, 31 Oct 2006 20:59:24 GMT
Actually, no need to add the overhead to _all_ cycles. We don't need
to trace the vtables everytime. On minor collections all the pinned
vtables can be linearly scanned, thus most expensive tracing from
object to vtable can be avoided in this case.

Intel Enterprise Solutions Software Division

On 10/31/06, Etienne Gagnon <egagnon@sablevm.org> wrote:
> Actually, I think that Java vtables would be more expensive than my
> proposed approach (when you take my proposed improvements in my reply to
> Pavel Pervov), as you add overhead to all GC cycles!  [Unless you don't
> "trace" from every visited object to its vtable?]
> I really don't like much the idea of an "object" vtable.  It requires
> things such as "pinning", etc.  Looks more expensive than my solution.
> Etienne
> Rana Dasgupta wrote:
> > Etienne,
> >  This is a good design, thanks. Conceptually, reference counting in the VM
> > is somewhat similar to Aleksey's proposal 1, if I understand correctly.
> > This
> > design also requires quite a few hand-offs between the VM and GC. In DRLVM,
> > the problem is that we have quite a few GC's, not all within our control.
> >  However, it seems to me that we can either desire to make unloading
> > automatic, in which case, we will need things like java vtables etc and
> > leave most things to the GC. Or we can do refcounting or tracing in the VM,
> > and work lock step with the GC(s). I am not sure which is the better way.

View raw message