On 11/2/06, Robin Garner <[EMAIL PROTECTED]> wrote:
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.
Yes, I agree with all what you said. And DRLVM GCv4/v5 doesn't move
large objects at the moment.
Thanks,
xiaofeng
cheers
