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][GC] (HARMONY-2398) patch for GCv5 alloc helper inlining
Date Tue, 05 Dec 2006 10:28:19 GMT
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
>
>

Mime
View raw message