harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 30 Nov 2006 02:12:10 GMT
On 11/30/06, Robin Garner <robin.garner@anu.edu.au> 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/
>

Mime
View raw message