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 weldonwjw@gmail.com designates
 209.85.132.247 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:references;
        b=QYunM5jl8ugxDqJhJthfS1RDFerXvmBw3Wg873tMwzvwC8ocNbzZncOyVFuDbWlyKseO/klLMKtsfV6mk9ZTDhuKxMW1XGG6cOvrDVT1YfkFI9agHYHen2d+Hh9D0u/eOmYh+2ctxwhD7F842sAmXFvc9EVtHvrq2/EYDoFYSw0=
Message-ID: <4dd1f3f00701090711o5bcbd31eyafb1d2c068011d4b@mail.gmail.com>
Date: Tue, 9 Jan 2007 07:11:57 -0800
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM][JIT] write barrier broken by new jit opts?
In-Reply-To: <u8xgcsc6s.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_90735_15586912.1168355517073"
References: <9623c9a50701062159r685c12e4ga09b822536d335d9@mail.gmail.com>
	 <59515.210.11.146.248.1168153193.squirrel@sqmail.anu.edu.au>
	 <4dd1f3f00701071649q7105d51eg80d357487d682574@mail.gmail.com>
	 <u8xgcsc6s.fsf@gmail.com>

------=_Part_90735_15586912.1168355517073
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 09 Jan 2007 16:54:03 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> On the 0x258 day of Apache Harmony Weldon Washburn wrote:
> > It looks like multiple interesting design topics.  My comments inlined
> > below.
> >
> [..snip..]
> >
> > > 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,
> >
> > Yes.  But first how much performance is  being sacrificed?  .2%?  8%??
>
> JIT magic arraycopy gives up to 30% boost on a microbenchmark (see
> HARMONY-2247). I did not measure boosts on specific benchmarks, but I
> think users would expect System.arraycopy() to be pretty faster than
> manual array copying. We should care about performance numbers as
> such.


Let me re-phrase the question.  Arraycopy performance is important and
deserves the special case treatment it has always gotten.  Setting aside
arraycopy, how much performance gain can be expected by optimizing
consecutive writes to fields of an object for the benchmarks we care about?
What about simply marking the consecutive writes regions as
"Uninterruptible"?  This would eliminate yet another API between the GC and
JIT.  I think this is basically the same as Robin's suggestion.

Regarding arraycopy, is there a problem with making the entire arraycopy
loop "Uninterruptible"?  This will impact GC latency but is the impact a big
deal for workloads we care about?  If it is, why not have the compiler
unroll the loop a bunch and put WBs every, say, 10th write.  The body of 10
writes would be Uninterruptible.

> > 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.
> >
> > hmm.... what happens if some other app thread causes a GC to happen in
> the
> > middle of writing a bunch of fields of a given object?  If the
> > gc_heap_wrote_object() is called before JITed code scribbles on slots,
> then
> > the early slots will be scanned and handled properly by the GC.   But
> how do
> > we handle the slots written after the GC completes?  One approach would
> be
> > for the JIT to mark such regions of emitted code "Uninterruptable".
> > Another approach would be to emit a WB both before and after a region of
> > multiple ref field scribbles.   In any case, it looks like we need patch
> up
> > the holes in the contract between jit and gc.  However, as I said above
> is
> > there anything wrong with a real simple dumb contract for now?  That is
> each
> > ref write has a matching WB with no intervening instructions.
> >
> > >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
> > >
> >
> >
> >
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
>
> --
> Egor Pasko
>
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

------=_Part_90735_15586912.1168355517073--