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
