Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=rXH5iBDkpMhe1AmsRRHcqu5/lnL6zK35FVZFBt1JdCrYIptLAjOwfEjdMSu3d3ZW/VRSVsg/PuR7sKBTCfBPX0s6+e8rLZ3B15noTMa5FIWnUpm4Pr1YFjEgRsFaJNJ9po5NMAZXkFYdULzTyQ3DGidGEtysTMAbvib2zT0DsXY=
Message-ID: <9623c9a50611291651h777d283fnb6080a5d10497008@mail.gmail.com>
Date: Thu, 30 Nov 2006 08:51:57 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM][Helper inlining] GC write barrier inline?
In-Reply-To: <4dd1f3f00611290625y4fd0b388v72c7e859b1f920c9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9623c9a50611281757h3b8923d2o52e54adc857c073c@mail.gmail.com>
	 <4dd1f3f00611290625y4fd0b388v72c7e859b1f920c9@mail.gmail.com>

On 11/29/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> Xiao-Feng,
>
> Your suggestion below makes sense.  Have you given any thought where the
> Java code should reside in the source tree?  GCHelper is a Java class that
> looks to be specific to a given GC.   Does it end up in gcv5
> directory?   Also, does it make sense to inherit from vmmagic
> "Uninterruptible" class?

I think the helpers are GC specific, so it makes sense to put it into
its owning GC's directory. Yes, this write barrier will stay in GCv5
directory.

Mikhail Fursov has made very good contribution as to Java helpers
framework in his patch. I think it makes sense for the write barrier
to follow the conventions there, including the the interaction with
vmmagic.

Thanks,
xiaofeng

>
>
> On 11/28/06, Xiao-Feng Li <xiaofeng.li@gmail.com> 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);
> >    }
> >
> >    private static native Address getNosBoundary();
> > }
> >
> >
> > How do you think?
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>