harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Wed, 10 Jan 2007 06:46:11 GMT
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.   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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message