harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Thu, 11 Jan 2007 02:39:17 GMT
Egor Pasko wrote:
> On the 0x259 day of Apache Harmony Weldon Washburn wrote:
>> On 1/9/07, Robin Garner <robin.garner@anu.edu.au> 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.
> 
> 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 :)
> 

Until DRLVM gets into soft realtime workloads, which will need some kind
of incremental/concurrent collector, a delay of 1-2ms waiting for an
array copy shouldn't be a problem.  Testing with linux memcpy, a 512k 
array can be copied in ~1.5ms.  Calling the barrier every 512k (or 128K 
or 64k) of copy doesn't sound like too much of an overhead.

The fast array copy needs to disable GC, or reload base address and
recalculate offset continually in case the array(s) move during GC.  The 
array copy code would have to look something like:

copied = 0;
while (copied < size) {
   disableGC();
   srcPtr = src + copied;    // Reload in case GC occurred
   destPtr = dest + copied;
   copy_size = size - copied < CHUNK_SIZE ? size - copied : CHUNK_SIZE;
   object_write_barrier(dest);
   memcpy(destPtr,srcPtr,copy_size);  // Or equiv hand-generated code
   copied += copy_size;
   enableGC();
}

Since the barrier is an object remembering barrier, it doesn't need to
know which bit of the array has been copied, and can be called multiple
times on the same object.  Object remembering barriers have the 
advantage that they can set a 'remembered bit' in the object header and 
ensure they are only ever in the remset once.

cheers

-- 
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/


Mime
View raw message