You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Naveen Neelakantam <ne...@uiuc.edu> on 2007/04/07 20:16:29 UTC
[OT] Harmony used in accepted research paper
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
Re: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2B1 day of Apache Harmony Naveen Neelakantam 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.
cool!!
> 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.
Naveen, I forgot to tell you something .. i.e. you rock!
I am very excited about HARMONY-2012 improvements (which is "value
profiling"), a very popular topic for all JIT people.
> I'll post the patches after the weekend.
is it for ABCD too? :)
--
Egor Pasko
Re: [OT] Harmony used in accepted research paper
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thanks, Naveen, I've put the download link to the page as well. Thanks, xiaofeng
On 4/12/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
> I've added a citation for the paper to the wiki that Xiao-Feng setup.
>
> And here is a link to the paper: http://www-sal.cs.uiuc.edu/~zilles/
> papers/hardware_atomicity.isca2007.pdf
>
> 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 <ne...@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
> >>
>
>
--
http://xiao-feng.blogspot.com
Re: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
I've added a citation for the paper to the wiki that Xiao-Feng setup.
And here is a link to the paper: http://www-sal.cs.uiuc.edu/~zilles/
papers/hardware_atomicity.isca2007.pdf
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 <ne...@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
>>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 4/19/07, Naveen Neelakantam <ne...@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 <ne...@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 <pa...@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 <ne...@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
> >> >> > >>
> >> >> >
> >> >> >
> >> >>
> >>
> >>
>
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
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 <ne...@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 <pa...@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 <ne...@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
>> >> > >>
>> >> >
>> >> >
>> >>
>>
>>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
On Apr 18, 2007, at 12:24 AM, Pavel Ozhdikhin wrote:
> Naveen,
>
<snip>
> 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.
I believe it is safe to remove the following lines from
ValueProfiler.cpp:
// Note: for some strange reason, we can't always positively
identify abstract calls
if(profileAbstractCalls) {
profileAllVirtualCalls = true;
}
I can't reproduce the issue that caused me to put those lines in the
code.
Naveen
> -Pavel
<snip>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
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 <ne...@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 <pa...@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 <ne...@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
> >> > >>
> >> >
> >> >
> >>
>
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
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 <pa...@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 <ne...@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
>> > >>
>> >
>> >
>>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony
used in accepted research paper
Posted by Tim Ellison <t....@gmail.com>.
Pavel Ozhdikhin wrote:
> I've tested HARMONY-3630. Profile-guided devirtualizations gives ~2%
> improvement on SPECjbb2005 which is impressive!
Definitely worth having! Good job Naveen.
Tim
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
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 <pa...@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 <ne...@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
> > >>
> >
> >
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
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 <ne...@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 <ne...@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
> >>
>
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2C3 day of Apache Harmony Mikhail Fursov wrote:
> If you are Linux user you can check git: http://linux.yyz.us/git-howto.html
> I know Egor likes this system, so you have someone to ask
yep, it looks rather brain-damaging when you get first look, but then
you get used to it, becoming happy with quick operations on patches
(combining, excluding, etc.), blidingly fast branching, etc. Worth
trying.
> On 4/25/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
> >
> > Thanks Tim, I'll check it out.
> >
> > Naveen
> >
> > On Apr 21, 2007, at 3:48 AM, Tim Ellison wrote:
> >
> > > Naveen Neelakantam wrote:
> > >> Do you have a nice way of managing layers of patches? If so,
> > >> teach me!
> > >> :-)
> > >
> > > Quilt is popular ... http://savannah.nongnu.org/projects/quilt/
> > >
> > > HTH
> > >
> > > Tim
> >
> >
>
>
> --
> Mikhail Fursov
--
Egor Pasko
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Mikhail Fursov <mi...@gmail.com>.
If you are Linux user you can check git: http://linux.yyz.us/git-howto.html
I know Egor likes this system, so you have someone to ask
On 4/25/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
>
> Thanks Tim, I'll check it out.
>
> Naveen
>
> On Apr 21, 2007, at 3:48 AM, Tim Ellison wrote:
>
> > Naveen Neelakantam wrote:
> >> Do you have a nice way of managing layers of patches? If so,
> >> teach me!
> >> :-)
> >
> > Quilt is popular ... http://savannah.nongnu.org/projects/quilt/
> >
> > HTH
> >
> > Tim
>
>
--
Mikhail Fursov
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
Thanks Tim, I'll check it out.
Naveen
On Apr 21, 2007, at 3:48 AM, Tim Ellison wrote:
> Naveen Neelakantam wrote:
>> Do you have a nice way of managing layers of patches? If so,
>> teach me!
>> :-)
>
> Quilt is popular ... http://savannah.nongnu.org/projects/quilt/
>
> HTH
>
> Tim
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony
used in accepted research paper
Posted by Tim Ellison <t....@gmail.com>.
Naveen Neelakantam wrote:
> Do you have a nice way of managing layers of patches? If so, teach me!
> :-)
Quilt is popular ... http://savannah.nongnu.org/projects/quilt/
HTH
Tim
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2CA day of Apache Harmony Pavel Ozhdikhin wrote:
> Egor,
>
> Thanks for the patch! I needed to update it to run smoothly:
>
> < if ( dst &&
> > if ( dst && !dst->isNull() &&
oops :)
> and with the updated patch I've managed to pass the stress.Stack test.
> I'm re-running other tests to check if everything is fine now.
greater thanks!
> -Pavel
>
> On 02 May 2007 17:48:09 +0400, Egor Pasko <eg...@gmail.com> wrote:
> > On the 0x2CA day of Apache Harmony Pavel Ozhdikhin wrote:
> > > I've attached the stack trace, the compilation log and dot files in
> > > JIRA. Hope this'll help.
> >
> > Pavel, thanks for that. The bug is in the InequalityGraph creation
> > code that incorrectly assumes that integer results can be obtained
> > only by operations of type Integer. Which is not right for the inst,
> > where two unmanaged pinters are compared resulting in an int.
> >
> > Please, try this (untested) fix:
> > --- a/vm/jitrino/src/optimizer/abcd/classic_abcd.cpp
> > +++ b/vm/jitrino/src/optimizer/abcd/classic_abcd.cpp
> > @@ -211,6 +211,16 @@ void BuildInequalityGraphWalker::applyTo
> > Type::Tag inst_type = inst->getType();
> > if ( !Type::isInteger(inst_type) && inst_type != Type::Boolean &&
> > inst_type != Type::Char ) {
> > + // note: some operations of unsupported type can produce operands of
> > + // supported (int) types, for example,
> > + // inst-compare-two-unmanaged-pointers, we need these operands as
> > + // unconstrained in the graph
> > + Opnd* dst = inst->getDst();
> > + if ( dst &&
> > + (dst->getType()->isInteger() ||
> > + dst->getType()->isBoolean() ) ) {
> > + addOldOrCreateOpnd(dst)->setUnconstrained(true);
> > + }
> > return;
> > }
> > if ( inst->isUnconditionalBranch() || inst->isConditionalBranch() ||
> >
> >
> >
> > hope this helps
> > not having windows, sorry
> >
> > > Thanks,
> > > Pavel
> > >
> > > On 01 May 2007 14:25:33 +0400, Egor Pasko <eg...@gmail.com> wrote:
> > > > On the 0x2C9 day of Apache Harmony Naveen Neelakantam wrote:
> > > > > On Apr 25, 2007, at 7:14 PM, Naveen Neelakantam wrote:
> > > > >
> > > > > >
> > > > > > On Apr 25, 2007, at 9:06 AM, Pavel Ozhdikhin wrote:
> > > > > >
> > > > > >> On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > > >
> > > > > <snip>
> > > > >
> > > > > >>> I've started looking into this patch. I've run into compilation
> > > > > >>> problems
> > > > > >>> on VS .NET 2003. I can update the patch and test it before
> > > > > >>> integration to
> > > > > >>> SVN, if you don't mind. Is there anything preventing us from
> > > > > >>> including the
> > > > > >>> new ABCD into the server optimization path? I can also update the
> > > > > >>> emconf
> > > > > >>> files to put classic_abcd in place of the old abcd pass.
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> Naveen,
> > > > > >>
> > > > > >> I've updated the patch but ran into the smoke test failure in -
> > > > > >> Xem:server
> > > > > >> mode. Please see details in the JIRA.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Pavel
> > > > > >
> > > > > > I'll take a look, but I need to setup a Windows dev environment first.
> > > > >
> > > > > There goes that plan. I've tried building on two completely
> > > > > different windows setups (Windows 2003 + .NET 2003, Windows XP + .NET
> > > > > 2005) and couldn't get harmony built on either.
> > > > >
> > > > > So, I'm stalled trying to reproduce the failure.
> > > >
> > > > I think, if would be great if Pavel gave us a log with the stack trace...
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> > >
> >
> > --
> > Egor Pasko
> >
> >
>
--
Egor Pasko
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
Egor,
Thanks for the patch! I needed to update it to run smoothly:
< if ( dst &&
> if ( dst && !dst->isNull() &&
and with the updated patch I've managed to pass the stress.Stack test.
I'm re-running other tests to check if everything is fine now.
-Pavel
On 02 May 2007 17:48:09 +0400, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x2CA day of Apache Harmony Pavel Ozhdikhin wrote:
> > I've attached the stack trace, the compilation log and dot files in
> > JIRA. Hope this'll help.
>
> Pavel, thanks for that. The bug is in the InequalityGraph creation
> code that incorrectly assumes that integer results can be obtained
> only by operations of type Integer. Which is not right for the inst,
> where two unmanaged pinters are compared resulting in an int.
>
> Please, try this (untested) fix:
> --- a/vm/jitrino/src/optimizer/abcd/classic_abcd.cpp
> +++ b/vm/jitrino/src/optimizer/abcd/classic_abcd.cpp
> @@ -211,6 +211,16 @@ void BuildInequalityGraphWalker::applyTo
> Type::Tag inst_type = inst->getType();
> if ( !Type::isInteger(inst_type) && inst_type != Type::Boolean &&
> inst_type != Type::Char ) {
> + // note: some operations of unsupported type can produce operands of
> + // supported (int) types, for example,
> + // inst-compare-two-unmanaged-pointers, we need these operands as
> + // unconstrained in the graph
> + Opnd* dst = inst->getDst();
> + if ( dst &&
> + (dst->getType()->isInteger() ||
> + dst->getType()->isBoolean() ) ) {
> + addOldOrCreateOpnd(dst)->setUnconstrained(true);
> + }
> return;
> }
> if ( inst->isUnconditionalBranch() || inst->isConditionalBranch() ||
>
>
>
> hope this helps
> not having windows, sorry
>
> > Thanks,
> > Pavel
> >
> > On 01 May 2007 14:25:33 +0400, Egor Pasko <eg...@gmail.com> wrote:
> > > On the 0x2C9 day of Apache Harmony Naveen Neelakantam wrote:
> > > > On Apr 25, 2007, at 7:14 PM, Naveen Neelakantam wrote:
> > > >
> > > > >
> > > > > On Apr 25, 2007, at 9:06 AM, Pavel Ozhdikhin wrote:
> > > > >
> > > > >> On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > > >
> > > > <snip>
> > > >
> > > > >>> I've started looking into this patch. I've run into compilation
> > > > >>> problems
> > > > >>> on VS .NET 2003. I can update the patch and test it before
> > > > >>> integration to
> > > > >>> SVN, if you don't mind. Is there anything preventing us from
> > > > >>> including the
> > > > >>> new ABCD into the server optimization path? I can also update the
> > > > >>> emconf
> > > > >>> files to put classic_abcd in place of the old abcd pass.
> > > > >>>
> > > > >>
> > > > >>
> > > > >> Naveen,
> > > > >>
> > > > >> I've updated the patch but ran into the smoke test failure in -
> > > > >> Xem:server
> > > > >> mode. Please see details in the JIRA.
> > > > >>
> > > > >> Thanks,
> > > > >> Pavel
> > > > >
> > > > > I'll take a look, but I need to setup a Windows dev environment first.
> > > >
> > > > There goes that plan. I've tried building on two completely
> > > > different windows setups (Windows 2003 + .NET 2003, Windows XP + .NET
> > > > 2005) and couldn't get harmony built on either.
> > > >
> > > > So, I'm stalled trying to reproduce the failure.
> > >
> > > I think, if would be great if Pavel gave us a log with the stack trace...
> > >
> > > --
> > > Egor Pasko
> > >
> > >
> >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2CA day of Apache Harmony Pavel Ozhdikhin wrote:
> I've attached the stack trace, the compilation log and dot files in
> JIRA. Hope this'll help.
Pavel, thanks for that. The bug is in the InequalityGraph creation
code that incorrectly assumes that integer results can be obtained
only by operations of type Integer. Which is not right for the inst,
where two unmanaged pinters are compared resulting in an int.
Please, try this (untested) fix:
--- a/vm/jitrino/src/optimizer/abcd/classic_abcd.cpp
+++ b/vm/jitrino/src/optimizer/abcd/classic_abcd.cpp
@@ -211,6 +211,16 @@ void BuildInequalityGraphWalker::applyTo
Type::Tag inst_type = inst->getType();
if ( !Type::isInteger(inst_type) && inst_type != Type::Boolean &&
inst_type != Type::Char ) {
+ // note: some operations of unsupported type can produce operands of
+ // supported (int) types, for example,
+ // inst-compare-two-unmanaged-pointers, we need these operands as
+ // unconstrained in the graph
+ Opnd* dst = inst->getDst();
+ if ( dst &&
+ (dst->getType()->isInteger() ||
+ dst->getType()->isBoolean() ) ) {
+ addOldOrCreateOpnd(dst)->setUnconstrained(true);
+ }
return;
}
if ( inst->isUnconditionalBranch() || inst->isConditionalBranch() ||
hope this helps
not having windows, sorry
> Thanks,
> Pavel
>
> On 01 May 2007 14:25:33 +0400, Egor Pasko <eg...@gmail.com> wrote:
> > On the 0x2C9 day of Apache Harmony Naveen Neelakantam wrote:
> > > On Apr 25, 2007, at 7:14 PM, Naveen Neelakantam wrote:
> > >
> > > >
> > > > On Apr 25, 2007, at 9:06 AM, Pavel Ozhdikhin wrote:
> > > >
> > > >> On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> > >
> > > <snip>
> > >
> > > >>> I've started looking into this patch. I've run into compilation
> > > >>> problems
> > > >>> on VS .NET 2003. I can update the patch and test it before
> > > >>> integration to
> > > >>> SVN, if you don't mind. Is there anything preventing us from
> > > >>> including the
> > > >>> new ABCD into the server optimization path? I can also update the
> > > >>> emconf
> > > >>> files to put classic_abcd in place of the old abcd pass.
> > > >>>
> > > >>
> > > >>
> > > >> Naveen,
> > > >>
> > > >> I've updated the patch but ran into the smoke test failure in -
> > > >> Xem:server
> > > >> mode. Please see details in the JIRA.
> > > >>
> > > >> Thanks,
> > > >> Pavel
> > > >
> > > > I'll take a look, but I need to setup a Windows dev environment first.
> > >
> > > There goes that plan. I've tried building on two completely
> > > different windows setups (Windows 2003 + .NET 2003, Windows XP + .NET
> > > 2005) and couldn't get harmony built on either.
> > >
> > > So, I'm stalled trying to reproduce the failure.
> >
> > I think, if would be great if Pavel gave us a log with the stack trace...
> >
> > --
> > Egor Pasko
> >
> >
>
--
Egor Pasko
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
I've attached the stack trace, the compilation log and dot files in
JIRA. Hope this'll help.
Thanks,
Pavel
On 01 May 2007 14:25:33 +0400, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x2C9 day of Apache Harmony Naveen Neelakantam wrote:
> > On Apr 25, 2007, at 7:14 PM, Naveen Neelakantam wrote:
> >
> > >
> > > On Apr 25, 2007, at 9:06 AM, Pavel Ozhdikhin wrote:
> > >
> > >> On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
> >
> > <snip>
> >
> > >>> I've started looking into this patch. I've run into compilation
> > >>> problems
> > >>> on VS .NET 2003. I can update the patch and test it before
> > >>> integration to
> > >>> SVN, if you don't mind. Is there anything preventing us from
> > >>> including the
> > >>> new ABCD into the server optimization path? I can also update the
> > >>> emconf
> > >>> files to put classic_abcd in place of the old abcd pass.
> > >>>
> > >>
> > >>
> > >> Naveen,
> > >>
> > >> I've updated the patch but ran into the smoke test failure in -
> > >> Xem:server
> > >> mode. Please see details in the JIRA.
> > >>
> > >> Thanks,
> > >> Pavel
> > >
> > > I'll take a look, but I need to setup a Windows dev environment first.
> >
> > There goes that plan. I've tried building on two completely
> > different windows setups (Windows 2003 + .NET 2003, Windows XP + .NET
> > 2005) and couldn't get harmony built on either.
> >
> > So, I'm stalled trying to reproduce the failure.
>
> I think, if would be great if Pavel gave us a log with the stack trace...
>
> --
> Egor Pasko
>
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2C9 day of Apache Harmony Naveen Neelakantam wrote:
> On Apr 25, 2007, at 7:14 PM, Naveen Neelakantam wrote:
>
> >
> > On Apr 25, 2007, at 9:06 AM, Pavel Ozhdikhin wrote:
> >
> >> On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>
> <snip>
>
> >>> I've started looking into this patch. I've run into compilation
> >>> problems
> >>> on VS .NET 2003. I can update the patch and test it before
> >>> integration to
> >>> SVN, if you don't mind. Is there anything preventing us from
> >>> including the
> >>> new ABCD into the server optimization path? I can also update the
> >>> emconf
> >>> files to put classic_abcd in place of the old abcd pass.
> >>>
> >>
> >>
> >> Naveen,
> >>
> >> I've updated the patch but ran into the smoke test failure in -
> >> Xem:server
> >> mode. Please see details in the JIRA.
> >>
> >> Thanks,
> >> Pavel
> >
> > I'll take a look, but I need to setup a Windows dev environment first.
>
> There goes that plan. I've tried building on two completely
> different windows setups (Windows 2003 + .NET 2003, Windows XP + .NET
> 2005) and couldn't get harmony built on either.
>
> So, I'm stalled trying to reproduce the failure.
I think, if would be great if Pavel gave us a log with the stack trace...
--
Egor Pasko
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
On Apr 25, 2007, at 7:14 PM, Naveen Neelakantam wrote:
>
> On Apr 25, 2007, at 9:06 AM, Pavel Ozhdikhin wrote:
>
>> On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
<snip>
>>> I've started looking into this patch. I've run into compilation
>>> problems
>>> on VS .NET 2003. I can update the patch and test it before
>>> integration to
>>> SVN, if you don't mind. Is there anything preventing us from
>>> including the
>>> new ABCD into the server optimization path? I can also update the
>>> emconf
>>> files to put classic_abcd in place of the old abcd pass.
>>>
>>
>>
>> Naveen,
>>
>> I've updated the patch but ran into the smoke test failure in -
>> Xem:server
>> mode. Please see details in the JIRA.
>>
>> Thanks,
>> Pavel
>
> I'll take a look, but I need to setup a Windows dev environment first.
There goes that plan. I've tried building on two completely
different windows setups (Windows 2003 + .NET 2003, Windows XP + .NET
2005) and couldn't get harmony built on either.
So, I'm stalled trying to reproduce the failure.
Naveen
> Naveen
>
>>
>>
>>> Thanks,
>>> Pavel
<snip>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
On Apr 25, 2007, at 9:06 AM, Pavel Ozhdikhin wrote:
> On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>>
>> On 4/21/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
>> >
>> >
>> > On Apr 20, 2007, at 4:45 AM, Egor Pasko wrote:
>> >
>> > > On the 0x2BE day of Apache Harmony Naveen Neelakantam wrote:
>> > >> On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
>> > >>
>> >
>> > <snip>
>> >
>> > >>> One major question for now: Why do we need two separate
>> inequality
>> > >>> graphs, for upper and lower bound problems? You name the
>> lower bound
>> >
>> > >>> graph as 'inverted', but I do not see any 'inverted' edges in
>> > >>> tests I
>> > >>> tried. It seems like we can merge two graphs into one in the
>> way
>> > >>> extra
>> > >>> pi edges they won't disturb each other.
>> > >>>
>> > >>> Do you have any quick counter-example to this approach (so I
>> do not
>> > >>> stagger for a long time searching it)?
>> > >>
>> > >> I could be wrong, but I think you need two different inequality
>> > >> graphs. If I recall correctly, the reason has to do with the
>> types
>> > >> of constraints inserted for conditional branch operations are
>> > >> different in the upper and lower bound problems.
>> > >
>> > > the only difference between the two graphs is controlled by
>> this new
>> > > version of code:
>> > >
>> > > void BuildInequalityGraphWalker::addPiEdgesForBounds
>> > > (IOpndProxy* dst, const PiBound& lb, const PiBound& ub)
>> > > {
>> > > if ( _isLower && !lb.isUndefined() ) {
>> > > addPiEdgesWithOneBoundInf(dst, false, lb);
>> > > }
>> > > else if ( !_isLower && !ub.isUndefined() ) {
>> > > addPiEdgesWithOneBoundInf(dst, true, ub);
>> > > }
>> > > }
>> > >
>> > > in case of the lower bound problem it adds the edge of the
>> interest
>> > > for the lower bound problem taking only one side of pi-
>> constraint. In
>> > > case of upper-bound problem, it takes the other side because
>> this is
>> > > what upper problem is interested in. That's right and works well.
>> > >
>> > > I am thinking of adding both sides of pi-constraint in both
>> upper and
>> > > lower cases. I think, it should work, but did not test it yet.
>> In this
>> > > case the graph should look exactly the same.
>> >
>> > I've looked at the inequality graphs produced for the upper and
>> lower
>> > bound problems for the sort method of BidirectionalBubbleSort, and
>> > they are quite different (I used your dot output support to look at
>> > them). I guess I am not sure what you mean by "the graph should
>> > look exactly the same". I am fairly certain they must be
>> different.
>> >
>> > Also, I am concerned about the implications on the e-SSA graph of
>> > always inserting both sides of a pi-constraint. In the upper bound
>> > problem, pi-nodes should only rename variables if they are involved
>> > in a valid upper bound constraint (and vice versa for the lower-
>> bound
>> > problem).
>> >
>> > These problems may only creep up if the pi-constraint has one side
>> > undefined (upper or lower). Perhaps we could just treat these
>> > specially, but all other pi-constraints would be identical for the
>> > upper and lower bound problems.
>> >
>> > Once upon a time I tried to use a single inequality graph to
>> > represent both the upper and lower bound problems, but I could
>> never
>> > get it to work. I eventually gave up and implemented the code you
>> > see. But that doesn't mean I'm necessarily right, just that I may
>> > not be patient enough. :-)
>> >
>> > > P.S.:
>> > > I realize that I invented not an ideal name for
>> > > addPiEdgesWithOneBoundInf() which does not properly describe
>> what this
>> > > function does. Since both bounds can be non-infinite and it still
>> > > works fine. I am going to collect similar small improvements
>> in 3-4
>> > > tiny patches and attach them to JIRA for further consideration.
>> >
>> > Do you have a nice way of managing layers of patches? If so, teach
>> > me! :-)
>> >
>> > Otherwise, maybe we should get someone to check the code into
>> SVN and
>> > then we can submit improvements against that?
>>
>>
>>
>> I've started looking into this patch. I've run into compilation
>> problems
>> on VS .NET 2003. I can update the patch and test it before
>> integration to
>> SVN, if you don't mind. Is there anything preventing us from
>> including the
>> new ABCD into the server optimization path? I can also update the
>> emconf
>> files to put classic_abcd in place of the old abcd pass.
>>
>
>
> Naveen,
>
> I've updated the patch but ran into the smoke test failure in -
> Xem:server
> mode. Please see details in the JIRA.
>
> Thanks,
> Pavel
I'll take a look, but I need to setup a Windows dev environment first.
Naveen
>
>
>> Thanks,
>> Pavel
>>
>> >
>> > >> I'll try to work up an example why tomorrow.
>> > >
>> > > that would be just great
>> >
>> > I tried... My head hurts and I haven't found a good example yet...
>> > ABCD is hard. sorry.
>> >
>> > Naveen
>> >
>> >
>> >
>> >
>>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 4/25/07, Pavel Ozhdikhin <pa...@gmail.com> wrote:
>
> On 4/21/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
> >
> >
> > On Apr 20, 2007, at 4:45 AM, Egor Pasko wrote:
> >
> > > On the 0x2BE day of Apache Harmony Naveen Neelakantam wrote:
> > >> On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
> > >>
> >
> > <snip>
> >
> > >>> One major question for now: Why do we need two separate inequality
> > >>> graphs, for upper and lower bound problems? You name the lower bound
> >
> > >>> graph as 'inverted', but I do not see any 'inverted' edges in
> > >>> tests I
> > >>> tried. It seems like we can merge two graphs into one in the way
> > >>> extra
> > >>> pi edges they won't disturb each other.
> > >>>
> > >>> Do you have any quick counter-example to this approach (so I do not
> > >>> stagger for a long time searching it)?
> > >>
> > >> I could be wrong, but I think you need two different inequality
> > >> graphs. If I recall correctly, the reason has to do with the types
> > >> of constraints inserted for conditional branch operations are
> > >> different in the upper and lower bound problems.
> > >
> > > the only difference between the two graphs is controlled by this new
> > > version of code:
> > >
> > > void BuildInequalityGraphWalker::addPiEdgesForBounds
> > > (IOpndProxy* dst, const PiBound& lb, const PiBound& ub)
> > > {
> > > if ( _isLower && !lb.isUndefined() ) {
> > > addPiEdgesWithOneBoundInf(dst, false, lb);
> > > }
> > > else if ( !_isLower && !ub.isUndefined() ) {
> > > addPiEdgesWithOneBoundInf(dst, true, ub);
> > > }
> > > }
> > >
> > > in case of the lower bound problem it adds the edge of the interest
> > > for the lower bound problem taking only one side of pi-constraint. In
> > > case of upper-bound problem, it takes the other side because this is
> > > what upper problem is interested in. That's right and works well.
> > >
> > > I am thinking of adding both sides of pi-constraint in both upper and
> > > lower cases. I think, it should work, but did not test it yet. In this
> > > case the graph should look exactly the same.
> >
> > I've looked at the inequality graphs produced for the upper and lower
> > bound problems for the sort method of BidirectionalBubbleSort, and
> > they are quite different (I used your dot output support to look at
> > them). I guess I am not sure what you mean by "the graph should
> > look exactly the same". I am fairly certain they must be different.
> >
> > Also, I am concerned about the implications on the e-SSA graph of
> > always inserting both sides of a pi-constraint. In the upper bound
> > problem, pi-nodes should only rename variables if they are involved
> > in a valid upper bound constraint (and vice versa for the lower-bound
> > problem).
> >
> > These problems may only creep up if the pi-constraint has one side
> > undefined (upper or lower). Perhaps we could just treat these
> > specially, but all other pi-constraints would be identical for the
> > upper and lower bound problems.
> >
> > Once upon a time I tried to use a single inequality graph to
> > represent both the upper and lower bound problems, but I could never
> > get it to work. I eventually gave up and implemented the code you
> > see. But that doesn't mean I'm necessarily right, just that I may
> > not be patient enough. :-)
> >
> > > P.S.:
> > > I realize that I invented not an ideal name for
> > > addPiEdgesWithOneBoundInf() which does not properly describe what this
> > > function does. Since both bounds can be non-infinite and it still
> > > works fine. I am going to collect similar small improvements in 3-4
> > > tiny patches and attach them to JIRA for further consideration.
> >
> > Do you have a nice way of managing layers of patches? If so, teach
> > me! :-)
> >
> > Otherwise, maybe we should get someone to check the code into SVN and
> > then we can submit improvements against that?
>
>
>
> I've started looking into this patch. I've run into compilation problems
> on VS .NET 2003. I can update the patch and test it before integration to
> SVN, if you don't mind. Is there anything preventing us from including the
> new ABCD into the server optimization path? I can also update the emconf
> files to put classic_abcd in place of the old abcd pass.
>
Naveen,
I've updated the patch but ran into the smoke test failure in -Xem:server
mode. Please see details in the JIRA.
Thanks,
Pavel
> Thanks,
> Pavel
>
> >
> > >> I'll try to work up an example why tomorrow.
> > >
> > > that would be just great
> >
> > I tried... My head hurts and I haven't found a good example yet...
> > ABCD is hard. sorry.
> >
> > Naveen
> >
> >
> >
> >
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 26 Apr 2007 00:05:19 +0400, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x2C3 day of Apache Harmony Pavel Ozhdikhin wrote:
> > On 4/21/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
> > >
> > >
> > > On Apr 20, 2007, at 4:45 AM, Egor Pasko wrote:
> > >
> > > > On the 0x2BE day of Apache Harmony Naveen Neelakantam wrote:
> > > >> On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
> > > >>
> > >
> > > <snip>
> > >
> > > >>> One major question for now: Why do we need two separate inequality
> > > >>> graphs, for upper and lower bound problems? You name the lower
> bound
> > > >>> graph as 'inverted', but I do not see any 'inverted' edges in
> > > >>> tests I
> > > >>> tried. It seems like we can merge two graphs into one in the way
> > > >>> extra
> > > >>> pi edges they won't disturb each other.
> > > >>>
> > > >>> Do you have any quick counter-example to this approach (so I do
> not
> > > >>> stagger for a long time searching it)?
> > > >>
> > > >> I could be wrong, but I think you need two different inequality
> > > >> graphs. If I recall correctly, the reason has to do with the types
> > > >> of constraints inserted for conditional branch operations are
> > > >> different in the upper and lower bound problems.
> > > >
> > > > the only difference between the two graphs is controlled by this new
> > > > version of code:
> > > >
> > > > void BuildInequalityGraphWalker::addPiEdgesForBounds
> > > > (IOpndProxy* dst, const PiBound& lb, const PiBound& ub)
> > > > {
> > > > if ( _isLower && !lb.isUndefined() ) {
> > > > addPiEdgesWithOneBoundInf(dst, false, lb);
> > > > }
> > > > else if ( !_isLower && !ub.isUndefined() ) {
> > > > addPiEdgesWithOneBoundInf(dst, true, ub);
> > > > }
> > > > }
> > > >
> > > > in case of the lower bound problem it adds the edge of the interest
> > > > for the lower bound problem taking only one side of pi-constraint.
> In
> > > > case of upper-bound problem, it takes the other side because this is
> > > > what upper problem is interested in. That's right and works well.
> > > >
> > > > I am thinking of adding both sides of pi-constraint in both upper
> and
> > > > lower cases. I think, it should work, but did not test it yet. In
> this
> > > > case the graph should look exactly the same.
> > >
> > > I've looked at the inequality graphs produced for the upper and lower
> > > bound problems for the sort method of BidirectionalBubbleSort, and
> > > they are quite different (I used your dot output support to look at
> > > them). I guess I am not sure what you mean by "the graph should
> > > look exactly the same". I am fairly certain they must be different.
> > >
> > > Also, I am concerned about the implications on the e-SSA graph of
> > > always inserting both sides of a pi-constraint. In the upper bound
> > > problem, pi-nodes should only rename variables if they are involved
> > > in a valid upper bound constraint (and vice versa for the lower-bound
> > > problem).
> > >
> > > These problems may only creep up if the pi-constraint has one side
> > > undefined (upper or lower). Perhaps we could just treat these
> > > specially, but all other pi-constraints would be identical for the
> > > upper and lower bound problems.
> > >
> > > Once upon a time I tried to use a single inequality graph to
> > > represent both the upper and lower bound problems, but I could never
> > > get it to work. I eventually gave up and implemented the code you
> > > see. But that doesn't mean I'm necessarily right, just that I may
> > > not be patient enough. :-)
> > >
> > > > P.S.:
> > > > I realize that I invented not an ideal name for
> > > > addPiEdgesWithOneBoundInf() which does not properly describe what
> this
> > > > function does. Since both bounds can be non-infinite and it still
> > > > works fine. I am going to collect similar small improvements in 3-4
> > > > tiny patches and attach them to JIRA for further consideration.
> > >
> > > Do you have a nice way of managing layers of patches? If so, teach
> > > me! :-)
> > >
> > > Otherwise, maybe we should get someone to check the code into SVN and
> > > then we can submit improvements against that?
> >
> >
> >
> > I've started looking into this patch. I've run into compilation problems
> on
> > VS .NET 2003. I can update the patch and test it before integration to
> SVN,
> > if you don't mind. Is there anything preventing us from including the
> new
> > ABCD into the server optimization path? I can also update the emconf
> files
> > to put classic_abcd in place of the old abcd pass.
>
> I think, almost nothing prevents us from committing it. I reviewed the
> most part. Although, the code can be somewhat polished towards better
> maintainability (logging, simplicity, performance), these issues are
> rather minor with respect to what is done and just works. So, I would
> be happy to see it committed and send small non-critical improvements
> later on.
>
> But we are now in the middle of "quick and short stabilizing", so,
> let's wait a little with this big feature. OK?
I'm fine to wait a week till JavaOne. It's another chance to better test the
patch. :)
Thanks,
Pavel
> Thanks,
> > Pavel
> >
> > >
> > > >> I'll try to work up an example why tomorrow.
> > > >
> > > > that would be just great
> > >
> > > I tried... My head hurts and I haven't found a good example yet...
> > > ABCD is hard. sorry.
> > >
> > > Naveen
> > >
> > >
> > >
> > >
>
> --
> Egor Pasko
>
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2C3 day of Apache Harmony Pavel Ozhdikhin wrote:
> On 4/21/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
> >
> >
> > On Apr 20, 2007, at 4:45 AM, Egor Pasko wrote:
> >
> > > On the 0x2BE day of Apache Harmony Naveen Neelakantam wrote:
> > >> On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
> > >>
> >
> > <snip>
> >
> > >>> One major question for now: Why do we need two separate inequality
> > >>> graphs, for upper and lower bound problems? You name the lower bound
> > >>> graph as 'inverted', but I do not see any 'inverted' edges in
> > >>> tests I
> > >>> tried. It seems like we can merge two graphs into one in the way
> > >>> extra
> > >>> pi edges they won't disturb each other.
> > >>>
> > >>> Do you have any quick counter-example to this approach (so I do not
> > >>> stagger for a long time searching it)?
> > >>
> > >> I could be wrong, but I think you need two different inequality
> > >> graphs. If I recall correctly, the reason has to do with the types
> > >> of constraints inserted for conditional branch operations are
> > >> different in the upper and lower bound problems.
> > >
> > > the only difference between the two graphs is controlled by this new
> > > version of code:
> > >
> > > void BuildInequalityGraphWalker::addPiEdgesForBounds
> > > (IOpndProxy* dst, const PiBound& lb, const PiBound& ub)
> > > {
> > > if ( _isLower && !lb.isUndefined() ) {
> > > addPiEdgesWithOneBoundInf(dst, false, lb);
> > > }
> > > else if ( !_isLower && !ub.isUndefined() ) {
> > > addPiEdgesWithOneBoundInf(dst, true, ub);
> > > }
> > > }
> > >
> > > in case of the lower bound problem it adds the edge of the interest
> > > for the lower bound problem taking only one side of pi-constraint. In
> > > case of upper-bound problem, it takes the other side because this is
> > > what upper problem is interested in. That's right and works well.
> > >
> > > I am thinking of adding both sides of pi-constraint in both upper and
> > > lower cases. I think, it should work, but did not test it yet. In this
> > > case the graph should look exactly the same.
> >
> > I've looked at the inequality graphs produced for the upper and lower
> > bound problems for the sort method of BidirectionalBubbleSort, and
> > they are quite different (I used your dot output support to look at
> > them). I guess I am not sure what you mean by "the graph should
> > look exactly the same". I am fairly certain they must be different.
> >
> > Also, I am concerned about the implications on the e-SSA graph of
> > always inserting both sides of a pi-constraint. In the upper bound
> > problem, pi-nodes should only rename variables if they are involved
> > in a valid upper bound constraint (and vice versa for the lower-bound
> > problem).
> >
> > These problems may only creep up if the pi-constraint has one side
> > undefined (upper or lower). Perhaps we could just treat these
> > specially, but all other pi-constraints would be identical for the
> > upper and lower bound problems.
> >
> > Once upon a time I tried to use a single inequality graph to
> > represent both the upper and lower bound problems, but I could never
> > get it to work. I eventually gave up and implemented the code you
> > see. But that doesn't mean I'm necessarily right, just that I may
> > not be patient enough. :-)
> >
> > > P.S.:
> > > I realize that I invented not an ideal name for
> > > addPiEdgesWithOneBoundInf() which does not properly describe what this
> > > function does. Since both bounds can be non-infinite and it still
> > > works fine. I am going to collect similar small improvements in 3-4
> > > tiny patches and attach them to JIRA for further consideration.
> >
> > Do you have a nice way of managing layers of patches? If so, teach
> > me! :-)
> >
> > Otherwise, maybe we should get someone to check the code into SVN and
> > then we can submit improvements against that?
>
>
>
> I've started looking into this patch. I've run into compilation problems on
> VS .NET 2003. I can update the patch and test it before integration to SVN,
> if you don't mind. Is there anything preventing us from including the new
> ABCD into the server optimization path? I can also update the emconf files
> to put classic_abcd in place of the old abcd pass.
I think, almost nothing prevents us from committing it. I reviewed the
most part. Although, the code can be somewhat polished towards better
maintainability (logging, simplicity, performance), these issues are
rather minor with respect to what is done and just works. So, I would
be happy to see it committed and send small non-critical improvements
later on.
But we are now in the middle of "quick and short stabilizing", so,
let's wait a little with this big feature. OK?
> Thanks,
> Pavel
>
> >
> > >> I'll try to work up an example why tomorrow.
> > >
> > > that would be just great
> >
> > I tried... My head hurts and I haven't found a good example yet...
> > ABCD is hard. sorry.
> >
> > Naveen
> >
> >
> >
> >
--
Egor Pasko
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
On 4/21/07, Naveen Neelakantam <ne...@uiuc.edu> wrote:
>
>
> On Apr 20, 2007, at 4:45 AM, Egor Pasko wrote:
>
> > On the 0x2BE day of Apache Harmony Naveen Neelakantam wrote:
> >> On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
> >>
>
> <snip>
>
> >>> One major question for now: Why do we need two separate inequality
> >>> graphs, for upper and lower bound problems? You name the lower bound
> >>> graph as 'inverted', but I do not see any 'inverted' edges in
> >>> tests I
> >>> tried. It seems like we can merge two graphs into one in the way
> >>> extra
> >>> pi edges they won't disturb each other.
> >>>
> >>> Do you have any quick counter-example to this approach (so I do not
> >>> stagger for a long time searching it)?
> >>
> >> I could be wrong, but I think you need two different inequality
> >> graphs. If I recall correctly, the reason has to do with the types
> >> of constraints inserted for conditional branch operations are
> >> different in the upper and lower bound problems.
> >
> > the only difference between the two graphs is controlled by this new
> > version of code:
> >
> > void BuildInequalityGraphWalker::addPiEdgesForBounds
> > (IOpndProxy* dst, const PiBound& lb, const PiBound& ub)
> > {
> > if ( _isLower && !lb.isUndefined() ) {
> > addPiEdgesWithOneBoundInf(dst, false, lb);
> > }
> > else if ( !_isLower && !ub.isUndefined() ) {
> > addPiEdgesWithOneBoundInf(dst, true, ub);
> > }
> > }
> >
> > in case of the lower bound problem it adds the edge of the interest
> > for the lower bound problem taking only one side of pi-constraint. In
> > case of upper-bound problem, it takes the other side because this is
> > what upper problem is interested in. That's right and works well.
> >
> > I am thinking of adding both sides of pi-constraint in both upper and
> > lower cases. I think, it should work, but did not test it yet. In this
> > case the graph should look exactly the same.
>
> I've looked at the inequality graphs produced for the upper and lower
> bound problems for the sort method of BidirectionalBubbleSort, and
> they are quite different (I used your dot output support to look at
> them). I guess I am not sure what you mean by "the graph should
> look exactly the same". I am fairly certain they must be different.
>
> Also, I am concerned about the implications on the e-SSA graph of
> always inserting both sides of a pi-constraint. In the upper bound
> problem, pi-nodes should only rename variables if they are involved
> in a valid upper bound constraint (and vice versa for the lower-bound
> problem).
>
> These problems may only creep up if the pi-constraint has one side
> undefined (upper or lower). Perhaps we could just treat these
> specially, but all other pi-constraints would be identical for the
> upper and lower bound problems.
>
> Once upon a time I tried to use a single inequality graph to
> represent both the upper and lower bound problems, but I could never
> get it to work. I eventually gave up and implemented the code you
> see. But that doesn't mean I'm necessarily right, just that I may
> not be patient enough. :-)
>
> > P.S.:
> > I realize that I invented not an ideal name for
> > addPiEdgesWithOneBoundInf() which does not properly describe what this
> > function does. Since both bounds can be non-infinite and it still
> > works fine. I am going to collect similar small improvements in 3-4
> > tiny patches and attach them to JIRA for further consideration.
>
> Do you have a nice way of managing layers of patches? If so, teach
> me! :-)
>
> Otherwise, maybe we should get someone to check the code into SVN and
> then we can submit improvements against that?
I've started looking into this patch. I've run into compilation problems on
VS .NET 2003. I can update the patch and test it before integration to SVN,
if you don't mind. Is there anything preventing us from including the new
ABCD into the server optimization path? I can also update the emconf files
to put classic_abcd in place of the old abcd pass.
Thanks,
Pavel
>
> >> I'll try to work up an example why tomorrow.
> >
> > that would be just great
>
> I tried... My head hurts and I haven't found a good example yet...
> ABCD is hard. sorry.
>
> Naveen
>
>
>
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
On Apr 20, 2007, at 4:45 AM, Egor Pasko wrote:
> On the 0x2BE day of Apache Harmony Naveen Neelakantam wrote:
>> On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
>>
<snip>
>>> One major question for now: Why do we need two separate inequality
>>> graphs, for upper and lower bound problems? You name the lower bound
>>> graph as 'inverted', but I do not see any 'inverted' edges in
>>> tests I
>>> tried. It seems like we can merge two graphs into one in the way
>>> extra
>>> pi edges they won't disturb each other.
>>>
>>> Do you have any quick counter-example to this approach (so I do not
>>> stagger for a long time searching it)?
>>
>> I could be wrong, but I think you need two different inequality
>> graphs. If I recall correctly, the reason has to do with the types
>> of constraints inserted for conditional branch operations are
>> different in the upper and lower bound problems.
>
> the only difference between the two graphs is controlled by this new
> version of code:
>
> void BuildInequalityGraphWalker::addPiEdgesForBounds
> (IOpndProxy* dst, const PiBound& lb, const PiBound& ub)
> {
> if ( _isLower && !lb.isUndefined() ) {
> addPiEdgesWithOneBoundInf(dst, false, lb);
> }
> else if ( !_isLower && !ub.isUndefined() ) {
> addPiEdgesWithOneBoundInf(dst, true, ub);
> }
> }
>
> in case of the lower bound problem it adds the edge of the interest
> for the lower bound problem taking only one side of pi-constraint. In
> case of upper-bound problem, it takes the other side because this is
> what upper problem is interested in. That's right and works well.
>
> I am thinking of adding both sides of pi-constraint in both upper and
> lower cases. I think, it should work, but did not test it yet. In this
> case the graph should look exactly the same.
I've looked at the inequality graphs produced for the upper and lower
bound problems for the sort method of BidirectionalBubbleSort, and
they are quite different (I used your dot output support to look at
them). I guess I am not sure what you mean by "the graph should
look exactly the same". I am fairly certain they must be different.
Also, I am concerned about the implications on the e-SSA graph of
always inserting both sides of a pi-constraint. In the upper bound
problem, pi-nodes should only rename variables if they are involved
in a valid upper bound constraint (and vice versa for the lower-bound
problem).
These problems may only creep up if the pi-constraint has one side
undefined (upper or lower). Perhaps we could just treat these
specially, but all other pi-constraints would be identical for the
upper and lower bound problems.
Once upon a time I tried to use a single inequality graph to
represent both the upper and lower bound problems, but I could never
get it to work. I eventually gave up and implemented the code you
see. But that doesn't mean I'm necessarily right, just that I may
not be patient enough. :-)
> P.S.:
> I realize that I invented not an ideal name for
> addPiEdgesWithOneBoundInf() which does not properly describe what this
> function does. Since both bounds can be non-infinite and it still
> works fine. I am going to collect similar small improvements in 3-4
> tiny patches and attach them to JIRA for further consideration.
Do you have a nice way of managing layers of patches? If so, teach
me! :-)
Otherwise, maybe we should get someone to check the code into SVN and
then we can submit improvements against that?
>
>> I'll try to work up an example why tomorrow.
>
> that would be just great
I tried... My head hurts and I haven't found a good example yet...
ABCD is hard. sorry.
Naveen
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2BE day of Apache Harmony Naveen Neelakantam wrote:
> On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
>
> > On the 0x2B6 day of Apache Harmony Naveen Neelakantam 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.
> >
> > Naveen, I am somewhere in the middle of looking at your great
> > work. Sorry for being so slow, but, you know, making sure that ABCD
> > works as expected is not an easy thing to do :)
>
> Indeed. :-)
>
> > One major question for now: Why do we need two separate inequality
> > graphs, for upper and lower bound problems? You name the lower bound
> > graph as 'inverted', but I do not see any 'inverted' edges in tests I
> > tried. It seems like we can merge two graphs into one in the way extra
> > pi edges they won't disturb each other.
> >
> > Do you have any quick counter-example to this approach (so I do not
> > stagger for a long time searching it)?
>
> I could be wrong, but I think you need two different inequality
> graphs. If I recall correctly, the reason has to do with the types
> of constraints inserted for conditional branch operations are
> different in the upper and lower bound problems.
the only difference between the two graphs is controlled by this new
version of code:
void BuildInequalityGraphWalker::addPiEdgesForBounds
(IOpndProxy* dst, const PiBound& lb, const PiBound& ub)
{
if ( _isLower && !lb.isUndefined() ) {
addPiEdgesWithOneBoundInf(dst, false, lb);
}
else if ( !_isLower && !ub.isUndefined() ) {
addPiEdgesWithOneBoundInf(dst, true, ub);
}
}
in case of the lower bound problem it adds the edge of the interest
for the lower bound problem taking only one side of pi-constraint. In
case of upper-bound problem, it takes the other side because this is
what upper problem is interested in. That's right and works well.
I am thinking of adding both sides of pi-constraint in both upper and
lower cases. I think, it should work, but did not test it yet. In this
case the graph should look exactly the same.
P.S.:
I realize that I invented not an ideal name for
addPiEdgesWithOneBoundInf() which does not properly describe what this
function does. Since both bounds can be non-infinite and it still
works fine. I am going to collect similar small improvements in 3-4
tiny patches and attach them to JIRA for further consideration.
> I'll try to work up an example why tomorrow.
that would be just great
>
> But maybe you are suggesting that we could have a single data-
> structure that logically represents both the upper and lower bound
> problems. If so, I think that might be possible (and would certainly
> be more efficient).
>
> Naveen
>
> >
> > Will ask/comment more soon.
> >
> >> 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 <ne...@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
> >>>>
> >>
> >>
> >
> > --
> > Egor Pasko
> >
>
>
--
Egor Pasko
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
On Apr 20, 2007, at 1:42 AM, Egor Pasko wrote:
> On the 0x2B6 day of Apache Harmony Naveen Neelakantam 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.
>
> Naveen, I am somewhere in the middle of looking at your great
> work. Sorry for being so slow, but, you know, making sure that ABCD
> works as expected is not an easy thing to do :)
Indeed. :-)
> One major question for now: Why do we need two separate inequality
> graphs, for upper and lower bound problems? You name the lower bound
> graph as 'inverted', but I do not see any 'inverted' edges in tests I
> tried. It seems like we can merge two graphs into one in the way extra
> pi edges they won't disturb each other.
>
> Do you have any quick counter-example to this approach (so I do not
> stagger for a long time searching it)?
I could be wrong, but I think you need two different inequality
graphs. If I recall correctly, the reason has to do with the types
of constraints inserted for conditional branch operations are
different in the upper and lower bound problems.
I'll try to work up an example why tomorrow.
But maybe you are suggesting that we could have a single data-
structure that logically represents both the upper and lower bound
problems. If so, I think that might be possible (and would certainly
be more efficient).
Naveen
>
> Will ask/comment more soon.
>
>> 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 <ne...@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
>>>>
>>
>>
>
> --
> Egor Pasko
>
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2B6 day of Apache Harmony Naveen Neelakantam 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.
Naveen, I am somewhere in the middle of looking at your great
work. Sorry for being so slow, but, you know, making sure that ABCD
works as expected is not an easy thing to do :)
One major question for now: Why do we need two separate inequality
graphs, for upper and lower bound problems? You name the lower bound
graph as 'inverted', but I do not see any 'inverted' edges in tests I
tried. It seems like we can merge two graphs into one in the way extra
pi edges they won't disturb each other.
Do you have any quick counter-example to this approach (so I do not
stagger for a long time searching it)?
Will ask/comment more soon.
> 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 <ne...@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
> >>
>
>
--
Egor Pasko
Re: [drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Mikhail Fursov <mi...@gmail.com>.
Good work, Naveen!
BTW what is performance benefit of ABCD for bubble-sort algorithm? I
remember I used the same algorithm (bubble and qsort) to measure loop
unrolling performance impact.
I'm really curious in measuring cumulative effect of these optimizations now
:)
On 4/12/07, Naveen Neelakantam <ne...@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 <ne...@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
> >>
>
>
--
Mikhail Fursov
[drlvm][jit] abcd and devirtualizer patches was: [OT] Harmony used in accepted research paper
Posted by Naveen Neelakantam <ne...@uiuc.edu>.
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 <ne...@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
>>
Re: [OT] Harmony used in accepted research paper
Posted by Pavel Ozhdikhin <pa...@gmail.com>.
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 <ne...@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
>
Re: [OT] Harmony used in accepted research paper
Posted by Tim Ellison <t....@gmail.com>.
Congratulations on getting your paper accepted Naveen. Be sure to give
us the citation when you get it published for listing on the Harmony
website.
Regards,
Tim
Naveen Neelakantam 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
>
Re: [OT] Harmony used in accepted research paper
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x2B1 day of Apache Harmony Naveen Neelakantam 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.
BTW, one comment on this one:
// Note: is this an optimization? It prevents adding a link from
// unconstrained operands. This is always safe, and it shouldn't lose
// opportunity, but maybe we should discuss it to be sure?
if ( !src->isUnconstrained() ) {
...
_igraph->addEdge(...);
...
}
I marked operands unconstrained in case they do not fit into 64 bit
constants. We can not deal with them. Another case is when the
instruction is "not supported" by ABCD such as multiplication and many
others. So, it is not an optimization.
--
Egor Pasko
Re: [OT] Harmony used in accepted research paper
Posted by Rana Dasgupta <rd...@gmail.com>.
Great news. Hope a lot more will follow :-)
On 4/7/07, Naveen Neelakantam <ne...@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
>
Re: [OT] Harmony used in accepted research paper
Posted by Xiao-Feng Li <xi...@gmail.com>.
This is really cool!
Besides the shared presentation pool for Harmony, we should also have
a page to list the research papers using Harmony.
Thanks,
xiaofeng
On 4/8/07, Naveen Neelakantam <ne...@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
>
--
http://xiao-feng.blogspot.com