harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Date Wed, 18 Apr 2007 05:24:16 GMT
Naveen,

Unguard was invented at the times when Jitrino did not have value profile
and does the same thing as the value profile does but less precise. We don't
inline at the first compilation and devirtualization without inlining gives
only overhead. Since we can't predict where we'll miss in heuristic
devirtualization we should add value profile counters for every virtual call
- thus we double overhead. I think we should choose one approach to avoid
this.

I checked performance on SPECjbb2005 with your patch applied and with
unguard configuration disabled (this required a couple of fixes in scalar
replacement optimization which are not in SVN yet). In this test I did not
see any performance degradation on SPECjbb2005. This result makes me
thinking that unguard configuration should be disabled and we should use
pure profile-guided approach.

BTW what is the problem you encountered with identifying abstract calls? I'm
talking about this comment:in ValueProfiler.cpp:

// Note: for some strange reason, we can't always positively identify
abstract calls

If there is a bug I believe we should fix it.

-Pavel


On 4/17/07, Naveen Neelakantam <neelakan@uiuc.edu> wrote:
>
> Wow!  Thanks for testing it Pavel!
>
> However, should unguard be disabled?  As I understand it, won't most
> virtual calls be devirtualized using the static heuristic during
> first compilation?  It is fairly accurate, but unguard will remove
> the ones that are unprofitable.  This seems intelligent to me.
> Perhaps the profile-based devirtualization code should be modified so
> that it only devirtualizes virtual calls that have been unguarded?
>
> On the other hand, profile-based devirtualization will do the "right"
> thing every time.  So, maybe you are right and we should disable the
> static heuristic and unguard.
>
> What do you think?
>
> Naveen
>
>
> On Apr 17, 2007, at 8:14 AM, Pavel Ozhdikhin wrote:
>
> > I've tested HARMONY-3630. Profile-guided devirtualizations gives ~2%
> > improvement on SPECjbb2005 which is impressive! We should disable
> > unguard
> > config before integrating the patch - otherwise we'll devirtualize
> > virtual
> > calls twice. Also we should get rid of code duplication in
> > ValueProfiler.cpp.
> > I'm going to prepare the patch which includes removing unguard
> > config and
> > then we can integrate profile-guided devirt for abstract and
> > virtual calls.
> >
> > Thanks,
> > Pavel
> >
> >
> > On 4/12/07, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com> wrote:
> >>
> >> Naveen,
> >>
> >> It's great! Do you have any data about performance gain/profiling
> >> overhead
> >> for profile-guided devirtualization of virtual and abstract calls?
> >> Current
> >> agressive devirtualization with unguard pass works pretty well and
> >> it's
> >> interesting if we can beat it with value profile.
> >>
> >> I'm going to play with your patches a bit to better understand the
> >> performance overhead/gain implications. I'll comment about the
> >> results here
> >> on the dev list.
> >>
> >> Thanks,
> >> Pavel
> >>
> >>
> >>  On 4/12/07, Naveen Neelakantam <neelakan@uiuc.edu> wrote:
> >> >
> >> > I've uploaded a patch against Egor's ABCD implementation in
> >> > HARMONY-1788.   It passes the tests included with HARMONY-2141,
> >> > HARMONY-2144 and HARMONY-2147, and removes all but one bounds check
> >> > from BidirectionalBubbleSort in HARMONY-1564.  I've also ran the
> >> > DaCapo benchmarks using it and it doesn't seem to break anything.
> >> >
> >> > I've also opened a JIRA issue for my profile-based abstract and
> >> > virtual call devirtualization patch: HARMONY-3630.
> >> >
> >> > Naveen
> >> >
> >> > On Apr 9, 2007, at 12:23 AM, Pavel Ozhdikhin wrote:
> >> >
> >> > > Naveen,
> >> > >
> >> > > Congrartulations! I eager to read your paper - please announce a
> >> > > link here
> >> > > when it's available.
> >> > >
> >> > > I'm also looking forward to a new ABCD impementation from Egor
> >> and
> >> > > your -
> >> > > your both did a lot to make it working, now it's time to make use
> >> > > of it in
> >> > > Harmony.
> >> > >
> >> > > Thanks,
> >> > > Pavel
> >> > >
> >> > > On 4/8/07, Naveen Neelakantam < neelakan@uiuc.edu> wrote:
> >> > >>
> >> > >> Hello all,
> >> > >>
> >> > >> You might like to hear that a paper which used Apache Harmony
> >> as part
> >> > >> of a research infrastructure was accepted to ISCA 2007
> >> (International
> >> >
> >> > >> Symposium on Computer Architecture).  I will be presenting
> >> this work
> >> > >> in San Diego in June and will be sure to include a slide
> >> plugging
> >> > >> Harmony.
> >> > >>
> >> > >> I would like to thank all of the JVM and classlib developers
> >> who made
> >> >
> >> > >> such an endeavor even possible.  You are doing a wonderful
> >> job, and
> >> > >> it is much appreciated!  Please pat yourself on the back.  :-)
> >> > >>
> >> > >> BTW, in the process of doing this work I helped get Egor
> >> Pasko's ABCD
> >> >
> >> > >> reimplementation finished, and I added profile-based abstract
> >> call
> >> > >> and virtual devirtualization to the code from HARMONY-2012.
> >> I'll
> >> > >> post the patches after the weekend.
> >> > >>
> >> > >> Thanks again,
> >> > >> Naveen
> >> > >>
> >> >
> >> >
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message