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 Wed, 10 Jan 2007 06:08:32 GMT
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