On 10 Jan 2007 12:05:57 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x259 day of Apache Harmony Weldon Washburn wrote: > On 1/9/07, Robin Garner <[EMAIL PROTECTED]> wrote: > > > > > On 09 Jan 2007 16:54:03 +0600, Egor Pasko <[EMAIL PROTECTED]> 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
