On 11/30/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote: > Mikhail Fursov has finished the GC alloc helper inlining, it's > probably time to discuss the inlining for write barrier. Write barrier > is one of the top prioritized candidates for inlining, this is common > in known JVMs, and this is also GCv5's urgent need. > > The first version of write barrier code in Java can be something like > this (by following the one for gc_alloc): > > public class GCHelper { > static {System.loadLibrary("gc_gen");} > > /* NOS (nursery object space) is higher in address than other spaces. > The boundary currently is produced in GC initialization. It can > be a constant in future.*/ > public static final Address NOS_BOUNDARY = getNosBoundary(); > > public static void write_barrier_slot_rem(Address p_slot, Address > p_target) { > > /* If the slot is in NOS or the target is not in NOS, we simply > return*/ > if( p_slot.GE( NOS_BOUNDARY) || p_target.LT( NOS_BOUNDARY) ) > return; > > /* Otherwise, we need remember it in native code. */ > VMHelper.WriteBarrierSlotRem(p_slot, p_target);Shouldn't this be if( p_slot.LT( NOS_BOUNDARY) && p_target.GE( NOS_BOUNDARY) ) VMHelper.WriteBarrierSlotRem(p_slot, p_target); ?? Ie we're recording old-to-new pointers.
Robin, aren't they the same but exchanging the two branches of condition checking? :-) Thanks, xiaofeng
-- Robin Garner Dept. of Computer Science Australian National University http://cs.anu.edu.au/people/Robin.Garner/
