> 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. >> While object remembering barriers may be adequate for GCV5 there are a >> large family of GC algorithms that they are inadequate for, including >> reference counting and concurrent/incremental GCs. >> >> regards, >> Robin >> >> > Hi, I found write barrier in DRLVM can't catch all reference fields >> > updates, and the problem is identified to be caused by new jit opts >> > that do not observe the write barrier invariant for fields updates. >> > For example, JIT may generate code to copy consecutive fields of an >> > object without invoking write barrier. In order to revive the write >> > barrier functionality while not sacrificing the opt performance, I'd >> > suggest to introduce an object remember write barrier which will be >> > invoked after the object is copied. So the JIT doesn't need to insert >> > barrier for each field store. GC has an interface >> > gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert >> > only the runtime native call at first. Then later we can consider to >> > inline the object remembering barrier as well as the slot remembering >> > barrier. >> > >> > Thanks, >> > xiaofeng >> > >> >> >> > > -- > Egor Pasko > >
