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 Wed, 06 Dec 2006 00:15:36 GMT
On 12/6/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 12/5/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >
> > Xiao-Feng,
> > I have finished all inlining tasks planned for this week and now can start
> > WB inlining task.
> > I'm going to use your patch with allocation helper as basis (
> > http://issues.apache.org/jira/browse/HARMONY-2398), and I will be able to
> > post my patch (get the diff) only after H2398 is applied.
> >
> I hope I'll WB in a day or two. The only thing I need to know: what is the
> state of gc_gen? Which specs does it run? What can I use to test stability
> and performance of my changes?

Mikhail, thanks. GCv5 can run the SPEC benchmarks without problem. So
I guess SPECJBB2005 is good enough for your code test in both
performance and stability. I will work with you closely for any
support you may need. Well my observation is you are smart enough to
deal with it. ;-)  (There are a couple of configurations for GCv5 for
performance tuning, but I guess the default setting can already
exhibit the performance improvement.)

>
> I just committed 2398.  Let me know when you have the WB patch ready and I
> will try to commit it.

Thanks, Weldon.

> On 12/5/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> > >
> > > On 12/5/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > > On 12/4/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> > > > > > On 11/30/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> > > > > >> Xiao-Feng Li wrote:
> > > > > >> >
> > > > > >> >        /* 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? :-)
> > > > >
> > > > > Yes, of course.  Doh.  !(A|B) = !A&!B.
> > > > >
> > > > > I do think the second is clearer though :)
> > > >
> > > > Since I somehow am not a branch predictor fun, I am used to put the
> > > > common TRUE case in the branch condition so that the fast path can be
> > > > scheduled as fall-through branch automatically by the JIT. This might
> > > > be very old and obsolete C programming wisdom. :-)
> > >
> Actually, in modern compilers this may not work. I like approach used
> in linux kernel:
>
>   if (unlikely(expr)) {
>   }
>
> where 'unlikely' is highly compiler specific and defined something like:
>
> #define likely(x)       __builtin_expect(!!(x), 1)
> #define unlikely(x)     __builtin_expect(!!(x), 0)

Ivan, yes, that is the only way that really works without profiling
support. Some processors also take the hint from compiler for branch
prediction.

Thanks,
xiaofeng

>
> > > --
> > > Ivan
> > >
> >
> >
> >
> > --
> > Mikhail Fursov
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>

Mime
View raw message