harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Wed, 10 Jan 2007 10:14:53 GMT
Egor, thanks for the great help! GCv5 has already object remembering
barrier support. The interface is gc_heap_wrote_object(). Only thing
remaining is to add a query of gc_supports_object_remembering(). You
can safely assume it returns true before the code is in SVN.

Thanks,
xiaofeng

On 10 Jan 2007 12:08:32 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> On the 0x259 day of Apache Harmony Robin Garner wrote:
> > > On the 0x257 day of Apache Harmony Robin Garner wrote:
> > >> I disagree.  Partly from the point of view of eventual support for MMTk,
> > >> but also on more general grounds, in terms of support for future GC
> > >> algorithms.
> > >>
> > >> If the memory manager requires that the compiler invoke the write
> > >> barrier
> > >> for each pointer store, then it should honour the contract and do so.
> > >>
> > >> If you want to provide an object remembering barrier that the compiler
> > >> can
> > >> call as an optimization, then by all means do so, but the GC should not
> > >> be
> > >> forced to work around compiler 'optimizations' that break fundamental
> > >> interface contracts.
> > >
> > > That's what I think we should do. I see it like this:
> > >
> > > * JIT asks GC if it has_object_update_wb_feature()
> > >
> > > * JIT checks CompilationInterface.insertWriteBarriers()
> > >
> > > * if both true, JIT inserts code that update whole objects with a
> > >   single "object/array update barrier". If only second is true,
> > >   generate an ordinary code.
> > >
> > > * "object update barrier" should NOT be a GC safe point
> > >
> > > The scheme is not complicated and easy to implement in JIT. Just need
> > > to put the right checks in right places. It should not be difficult to
> > > implement the feature in GCv5, isn't it?
> > >
> > > In spite of introducng more state-dependant code, I think, the feature
> > > is worth it from performance point of view.
> >
> > This is what JikesRVM does, and yes, for some (macro) benchmarks it pays off.
>
> Xiao-Feng, how about implementing it for GCv5? I can help with the JIT
> part.
>
> P.S: As a temporary workaround, we can disable arraycopy via an option.
>
> --
> Egor Pasko
>
>

Mime
View raw message