Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
In-Reply-To: <59515.210.11.146.248.1168153193.squirrel@sqmail.anu.edu.au>
References: <9623c9a50701062159r685c12e4ga09b822536d335d9@mail.gmail.com>
 <59515.210.11.146.248.1168153193.squirrel@sqmail.anu.edu.au>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E7FF39AC-0D9A-4D73-A63A-083C51A50E49@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date: Sun, 7 Jan 2007 16:40:01 -0500
To: dev@harmony.apache.org

What's an object remembering barrier?

On Jan 7, 2007, at 1:59 AM, Robin Garner wrote:

> I disagree.  Partly from the point of view of eventual support for  
> MMTk,
> but also on more general grounds, in terms of support for future GC
> algorithms.
>
> If the memory manager requires that the compiler invoke the write  
> barrier
> for each pointer store, then it should honour the contract and do so.
>
> If you want to provide an object remembering barrier that the  
> compiler can
> call as an optimization, then by all means do so, but the GC should  
> not be
> forced to work around compiler 'optimizations' that break fundamental
> interface contracts.
>
> While object remembering barriers may be adequate for GCV5 there are a
> large family of GC algorithms that they are inadequate for, including
> reference counting and concurrent/incremental GCs.
>
> regards,
> Robin
>
>> Hi, I found write barrier in DRLVM can't catch all reference fields
>> updates, and the problem is identified to be caused by new jit opts
>> that do not observe the write barrier invariant for fields updates.
>> For example, JIT may generate code to copy consecutive fields of an
>> object without invoking write barrier. In order to revive the write
>> barrier functionality while not sacrificing the opt performance, I'd
>> suggest to introduce an object remember write barrier which will be
>> invoked after the object is copied. So the JIT doesn't need to insert
>> barrier for each field store. GC has an interface
>> gc_heap_wrote_object(p_obj) for this case.  I think it's ok to insert
>> only the runtime native call at first. Then later we can consider to
>> inline the object remembering barrier as well as the slot remembering
>> barrier.
>>
>> Thanks,
>> xiaofeng
>>
>
>