Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper

[Naveen Neelakantam]

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