Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Thu, 02 Nov 2006 16:44:32 +1100
From: Robin Garner <robin.garner@anu.edu.au>
Subject: Re: [drlvm][sablevm] Desing of Class Unloading Support
In-reply-to: <9623c9a50611010304s33a1ff00u928847ed8a161fc@mail.gmail.com>
To: harmony-dev@incubator.apache.org
Message-id: <454985C0.1090501@anu.edu.au>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com>
 <4547A6E4.5080903@sablevm.org>
 <12385bbd0610311259m1012cdadl4f9452dc336dbac7@mail.gmail.com>
 <4547BC2B.2080600@sablevm.org>
 <51d555c70610311454s24d2089cx7eeb9af17d7ebfaf@mail.gmail.com>
 <bc79dd600611010020n75ab087bm412f32c9ea757aca@mail.gmail.com>
 <u1wona3sj.fsf@gmail.com>
 <bc79dd600611010157m1e0def1eg82f9334c787969f9@mail.gmail.com>
 <uwt6f8osq.fsf@gmail.com>
 <bc79dd600611010246jcf6606cn50c769447dfca035@mail.gmail.com>
 <9623c9a50611010304s33a1ff00u928847ed8a161fc@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060918)

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.

cheers