harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][sablevm] Desing of Class Unloading Support
Date Thu, 02 Nov 2006 07:46:25 GMT
On 11/2/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> Xiao-Feng Li wrote:
> > On 11/1/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >> On 01 Nov 2006 16:05:41 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> >> >
> >> > On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
> >> > > On 01 Nov 2006 15:56:28 +0600, Egor Pasko <egor.pasko@gmail.com>
> >> wrote:
> >> > > >
> >> > > > agreed. not patching .. just reporting 'golden' VTable refs to
> >> GC, am
> >> > > > I right?
> >> > > >
> >> > > Yes, and everytime we report it to GC and GC moves an object - it
> >> > patches
> >> > > the address we report.
> >> >
> >> > so, by saying "patching" you insist to put immediate operands into
> >> > instructions? That's probably worth it, but it extends the JIT<->GC
> >> > interface. How about making a simple operand (reg/mem) as the first
> >> step?
> >>
> >>
> >> Egor, I thinks this is slightly more complicated problem. If vtable
> >> object
> >> is moved we must update all devirtualization points in every method
> >> compiled
> >> before. It can require an extension of JIT<->VM<->GC interface.
> >> Another solution I see is to collect info about all devirtualization
> >> points
> >> in JIT (code addrs) and report these addresses as enumeration roots.
> >> This is
> >> JIT-only solution, and disadvantage is a significant (~hot methods count)
> >> increase of number of objects reported.
> >>
> >> On the other hand I see no reasons to unpin vtables in the nearest future
> >> (Let's GC guru correct me). If you use special (freelist-type ?)
> >> allocator
> >> in GC the memory fragmentation when unloading pinned vtable objects
> >> could be
> >> low.
> >
> > Yes, vtable should never be moved except for very weird reason. And
> > yes, to pin certain amount of objects is not a big performance issue
> > (in both temporal and spatial wise).
> >
> > -xiaofeng
> >
> >> --
> >> Mikhail Fursov
> >>
> >>
>
> In MMTk, this kind of 'pinning' is an allocation-time policy decision of
> the type I was advocating in the GC helpers thread.  Once a GC allows
> for the idea of supporting multiple collection policies (which
> generational GC requires in any case), then adding a non-moving space to
> a memory manager is easy.
>
> Most memory managers will have a non-moving large object space no matter
>   what the primary collection policy is.  The DRLVM collectors have this
> too, don't they ?
> Pinning an object after allocation is a harder problem, but not
> something required in this case.

Yes, I agree with all what you said. And DRLVM GCv4/v5 doesn't move
large objects at the moment.

Thanks,
xiaofeng

> cheers
>
>

Mime
View raw message