harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Thu, 11 Jan 2007 11:56:04 GMT
On the 0x25B day of Apache Harmony Mikhail Fursov 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?

1. arraycopy is uninterruptable
2. big arrays may take long to copy

=> the thread doing a big array copying cannot be suspended for a long
time (which is a performance problem)

first solution that came into our mind is to copy by uninterruptable
chunks, WB after each chunk and check for suspension flag after each chunk. 

> 2) What does object_write_barrier(dest) report in algorithm with chunks?

it should report the chunk update. Of course, it should have have more
parameters to outline the exact chunk that has been updated.

> > 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.
> 
> 
> 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.

and type checks? IMHO, these checks are not GC-ish. It has to be one
more contract if we want to tickle with this performance issue. The
question is will it be a new CG-JIT contract or GC-VM contract (to
throw exceptions). I see no much difference here. Need to decide.

-- 
Egor Pasko


Mime
View raw message