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 gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date: 10 Jan 2007 12:05:57 +0600
Lines: 93
Message-ID: <uvejfct6i.fsf@gmail.com>
References: <9623c9a50701062159r685c12e4ga09b822536d335d9@mail.gmail.com>
 <59515.210.11.146.248.1168153193.squirrel@sqmail.anu.edu.au>
 <4dd1f3f00701071649q7105d51eg80d357487d682574@mail.gmail.com>
 <u8xgcsc6s.fsf@gmail.com>
 <4dd1f3f00701090711o5bcbd31eyafb1d2c068011d4b@mail.gmail.com>
 <62797.210.11.146.248.1168356713.squirrel@sqmail.anu.edu.au>
 <4dd1f3f00701090837sec6ac0co3e8554eeb3e3f4aa@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

On the 0x259 day of Apache Harmony Weldon Washburn wrote:
> On 1/9/07, Robin Garner <robin.garner@anu.edu.au> wrote:
> >
> > > 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.
> >
> > With arraycopy, much of the saving is in barrier costs themselves.  Apart
> > from the overhead on the write, there's a reduction in remset entries, and
> > the cost of scanning the object at GC time is minimal for a reference
> > array.
> >
> > The original motivating benchmark was jess iirc.
> >
> > Off the top of my head, if the barrier is called before any data is copied
> > I think the arraycopy code is GC-safe, provided another barrier call is
> > made after the GC and before the next pointer write.  It's probably better
> > to make the arraycopy code uninterruptible.
> 
> 
> Yes, I agree it's probably better to make the arraycopy code
> uninterrutible.  The only caution is the impact on GC latency.  Um, does
> this require a new additional API or can we simply use what is existing?

well, you are probably saying that "optimized version of arraycopy
should be uninterruptable". In general, arraycopy can thow exceptions
=> that should be a safepoint.

Anyway, GC latency is a good note to mention here. Ideally we could
separate an array in parts for copying and put safepoints in between
the parts (that would require an extra JIT->GC interface pecularity to
tell which part of the array the barrier corresponds to). Something
tells me (my gut?) that this "optimization" would not give anything in
real situations :)

> My gut feel is that scalars don't generally have enough pointers to make
> > the object remembering barrier worthwhile.
> 
> 
> That's my hunch also.  However, if someone wants to spend time analyzing
> enterprise workloads to discover if there is any cheese down that tunnel, I
> won't get in the way.

Anyway, these days object copying/moving is NOT performed by code
emitted by Jitrino, and this kind of behaviour is not going to be
implemented in the nearest future. Thus, it cannot be the root cause
of the original bug we are discussing. The only problem left is
arraycopy (recent changes in arraycopy impl makes me more confident in
this version)

-- 
Egor Pasko