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 Wed, 01 Nov 2006 11:04:46 GMT
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
>
>

Mime
View raw message