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 Thu, 11 Jan 2007 15:08:34 GMT
On 1/11/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>
> On 11 Jan 2007 17:26:13 +0600, Egor Pasko <egor.pasko@gmail.com> 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

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