On 4/19/07, Naveen Neelakantam <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 >> >> > >> >> >> > >> >> > >> >> >> >>
