harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naveen Neelakantam <neela...@uiuc.edu>
Subject Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Date Thu, 19 Apr 2007 04:30:03 GMT

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.

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
View raw message