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 Thu, 19 Apr 2007 05:09:05 GMT
On 4/19/07, Naveen Neelakantam <neelakan@uiuc.edu> wrote:
>
>
> On Apr 18, 2007, at 12:24 AM, Pavel Ozhdikhin wrote:
>
> > 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.
>
> That makes sense.  I agree with your conclusion.
>
> > 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 I recall correctly, if you try to profile _just_ abstract calls
> (and likewise only use profile-directed devirtualization of abstract
> calls) you can run into a situation where during first compilation a
> call that did not look abstract is not profiled, but during second-
> compilation the call is identified as abstract and when the JIT tries
> to look-up the profile for the call there isn't one.
>
> I'll see if I can reproduce the problem and get back to you, but I
> won't be able to give it a try until Friday.


Friday is fine, thanks!

-Pavel


Naveen
>
> > 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