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 <[EMAIL PROTECTED]> 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
