On 11/1/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 01 Nov 2006 16:05:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
>
> On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
> > On 01 Nov 2006 15:56:28 +0600, Egor Pasko <[EMAIL PROTECTED]> 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