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 13:07:08 +0600
Lines: 140
Message-ID: <uirffcqcj.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>
 <uvejfct6i.fsf@gmail.com>
 <4dd1f3f00701092246m3b798db1r6c30d1498eaad3b0@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 0x25A day of Apache Harmony Weldon Washburn wrote:
> On 10 Jan 2007 12:05:57 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> >
> > 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:
> 
> 
> 
> 
> > [snip]
> 
> 
> 
> > >
> > > > 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.
> 
> 
> Actually all the exceptions can be pre-screened and, if necessary, thrown
> before the copy loop. 

no, API spec says:

   if any actual component of the source array from position srcPos
   through srcPos+length-1 cannot be converted to the component type
   of the destination array by assignment conversion, an
   ArrayStoreException is thrown.

we optimize arraycopy only for primitive types and for cases when
declared src component class is a subclass for the dst component
type. See JavaByteCodeTranslator.cpp:2883
(JavaByteCodeTranslator::arraycopyOptimizable).

> Thus the copy loop can proceed w/o worry about exceptions.  Below
> are comments in the native method helper version (vm_arrays.h).
> Does the JIT do something similar to the code in
> vm_arrays.cpp::array_copy() ?
> 
> 
> VM_RT_CHAR_ARRAYCOPY_NO_EXC=950,
> 
> // Arguments:
> 
> // - Object reference for the source array. Must be non-null and refer to an
> array
> 
> // of 16 bit chars.
> 
> // - int32 containing the starting index of the source array to copy.
> 
> // - Object reference for the destination array. Must be non-null and refer
> to an array
> 
> // of 16 bit chars.
> 
> // - int32 containing the starting index of the destination array to copy
> into.
> 
> // - int32 containing the number of 16 bit chars to copy.
> 
> // Return value: none.
> 
> //
> 
> // This runtime helper function provides a specialized implementation for
> System.arraycopy
> 
> // for the common case where the elements of the arrays are
> 
> // 16 bit characters and the array references are both non-null. The JIT
> must guarantee
> 
> // that no exceptions will need to be thrown. That is, both array references
> are non-null,
> 
> // the types match (and are both arrays of 16 bit characters),
> 
> // and the starting indexes and length are such that the copying will only
> access
> 
> // data in the bounds of the arrays.
> Looking at
> 
> > 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
> >
> >
> 
> 
> -- 
> Weldon Washburn
> Intel Enterprise Solutions Software Division

-- 
Egor Pasko