harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][GC] (HARMONY-2398) patch for GCv5 alloc helper inlining
Date Tue, 05 Dec 2006 12:14:16 GMT
I think in order to do this comparison, other conditions should be
equal. Comparing helper with 1 dependent load in gc_cc and helper with
2 dependent loads in gc_v5 makes no sense to me.
--
Ivan

On 12/5/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> 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.

Mime
View raw message