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 64.233.184.235 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=I2tDtCHEnCMRIPqckKonKPctSR7ky+BCLm4+RYNlWJCScSdFIiFq4CJ2qL1Dq4F/j5O77uXSiW0QjUM9z0CLy0del+HPojPtzUjrkcJkhFlS5jgE1UidqF5Bh/RfEtNoV4KUuUGIQgVXDgTqOWZXGcHRVlHp0xj4xcj2qpQ9+ec=
Message-ID: <9623c9a50612050228i2cbddc72xcd6f966edbe662f3@mail.gmail.com>
Date: Tue, 5 Dec 2006 18:28:19 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM][GC] (HARMONY-2398) patch for GCv5 alloc helper inlining
In-Reply-To: <bc79dd600612042252y7615eb20m6d5b6c272c6a3ce4@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: <9623c9a50612030046l161a8c3fk6f50be5b34562dc0@mail.gmail.com>
	 <bc79dd600612040450q5338d5abo3186f30cd07deeb5@mail.gmail.com>
	 <9623c9a50612041607o54948d82v66d4868f976e91ee@mail.gmail.com>
	 <bc79dd600612042252y7615eb20m6d5b6c272c6a3ce4@mail.gmail.com>

On 12/5/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> Yes, now it's ok. As you see you need one extra memory load in comparison
> with GC_CC helper's version. Now I'm interested if it will or won't have a
> performance affect on microtests or specs.

I sometimes prefer readability and modularity to some marginal
performance improvement. Yes, let's see the performance impact of the
extra load. :)

( I guess it should have no problem since "free" and "ceiling" stay
together so one load will ensure the other one in cache. )

Thanks,
xiaofeng

> On 12/5/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > On 12/4/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > On 12/3/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > >
> > > > Hi, patch for GCv5 alloc inlining was submitted. This patch has also
> > > > some other improvement in parallel collection.
> > > >
> > > > Dear committer, please help to commit it at your early convenience.
> > > >
> > > > Mikhail, after the patch is committed, would you please have a look if
> > > > the inlining can work well with GCv5 allocation?  Thanks.
> > > >
> > > > I don't use two TLS values for the fast path allocation; instead, only
> > > > one TLS value is used for GC, and it is a pointer to the GC thread
> > > > local infomation. The code is the same logic as  gc_alloc_fast( )  in
> > > > file gc_gen/thread/mutator_alloc.cpp and gc_thread.h. (Except that the
> > > > Java code has no large object threshold check, that is only one
> > > > constant comparison anyway.)
> > > >
> > >
> > > Xiao-Feng,
> > > I checked the helper's part of the diff.
> > > I have a question about TLS usage in your code.
> > >
> > > You said that you use only one TLS slot to keep the pointer to
> > > GC_thread_info.
> > > In this case Java code of the helper is incorrect:
> > >
> > >         Address TLS_BASE = VMHelper.getTlsBaseAddress();
> > >
> > Oh, my mistake. I should modify the statement below:
> >
> > >         Address allocator = TLS_BASE.plus(TLS_GC_OFFSET);
> >
> > to be:
> >            Address allocator_addr = TLS_BASE.plus(TLS_GC_OFFSET);
> >            Address allocator = allocator_addr.loadAddress();
> >
> > Right? I will submit another patch. Thanks for pointing it out. :-)
> >
> > Thanks,
> > xiaofeng
> >
> >
> > >         Address free_addr = allocator.plus(0);
> > >         Address free = free_addr.loadAddress();
> > >
> > > I can fix it by myself after your patch is applied, of you can resubmit
> > the
> > > patch.
> > > --
> > > Mikhail Fursov
> > >
> > >
> >
>
>
>
> --
> Mikhail Fursov
>
>