On 1/11/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 11 Jan 2007 17:26:13 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote: > > On the 0x25B day of Apache Harmony Mikhail Fursov wrote: > > IMO disabling GC for inlined arraycopy IR region is a good idea and it > > should work. > > Other proposals from me here: > > 1) Why to report each object separately? May be calling wb helper once > with > > array of objects could be better? > > AFAIR, Robin proposed to report array updates by chunks, which is a > good idea for fast thread suspension. WB once for small arrays, wb > several times for large arrays. The issues that I did not understand from Robin's post are: 1) Why do we need chunks? 2) What does object_write_barrier(dest) report in algorithm with chunks? > 2) Another solution could be if GC will provide a helper written with > > vmmagic for array copying by itself? > > yes, that makes it a) more elegant/supportable than JIT magic b) has > GC specifics in GC. But on the other hand we should limit this vmmagic > functionality by the "optimized" part of arraycopy. All other > exception throwing pecularities are more natural to implement on JIT > or VM side.
Actually unless there is some compelling real app data it might make sense to hold off attempting any "chunk" optimization. I think Robin posted some numbers indicating gc latency for a big array copy is probably no big deal right now. Also, adding optimizations that don't help workloads we need to focus on can clutter the code, make debugging harder and reduce reliability. Dividing arraycopy into different parts implies additional layer in GC-JIT
communication in this case. I see no reasons why not to do nullpointer or bounds check in vmmagic helper. -- > Egor Pasko > > -- Mikhail Fursov
-- Weldon Washburn Intel Enterprise Solutions Software Division
