Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=oikS0/rAH061MdBB53vSUuIcpSk7V1w7qgeNtlvYFHwryrjo0QdQt5eOO3NU4xUTm0A5XGRYUDWyfUCdKYE0RQEQ9HO6xOXGisaOKZ8DI63otMvrRUtqHlRyS8BZ69GOmRma6i0MtaXewyLqPAq1af3V5GxAOSb3MwDAbO+AFtA=
Message-ID: <9623c9a50701071728l3f97defcr38b4e14a916e6b70@mail.gmail.com>
Date: Mon, 8 Jan 2007 09:28:11 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM][JIT] write barrier broken by new jit opts?
In-Reply-To: <E7FF39AC-0D9A-4D73-A63A-083C51A50E49@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9623c9a50701062159r685c12e4ga09b822536d335d9@mail.gmail.com>
	 <59515.210.11.146.248.1168153193.squirrel@sqmail.anu.edu.au>
	 <E7FF39AC-0D9A-4D73-A63A-083C51A50E49@pobox.com>

On 1/8/07, Geir Magnusson Jr. <geir@pobox.com> wrote:

> What's an object remembering barrier?

It is to remeber an object whose reference fields are written.

Usually, the JIT inserts code for every reference field write, which
is called slot remembering. Recently, some jit opts generate code for
object copy in bulk, i.e., multiple fields are copied once together,
which doesn't insert slot barrier for individual field. In this case,
a straightforward solution is to remember the object after the copy.
GC will scan the object to find the reference fields of its interests.

Thanks,
xiaofeng

> 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
> >>
> >
> >
>
>