Xiao-Feng Li wrote:
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
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.
cheers
