harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Tue, 29 Apr 2008 02:11:44 GMT
On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:

> On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <ndbeyer@apache.org<https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>>
> wrote:
> > What about non-classlib code? If the JIT isn't going to get any better
> then
> >  user code is still going to have inline opportunities missed, correct?
>
> Right. That's something depending on JIT's capability.
>
> >  This seems like a tactical approach to get faster JRE code in the
> short-term
> >  that won't provide any benefit in the long-term. I'd rather advocate
> >  spending egnergy on more strategic concerns.
>
> I agree. The problem is, to improve JIT to cover all the important
> cases is, unfortunately in my estimation, a long and huge effort. And
> JIT has certain limit, which is always not as smart as human being. We
> can't expect it can improve in short term. I don't mean JIT will not
> improve. They are two simultaneous efforts. Putting annotation doesn't
> exclude any JIT improvement efforts.


So this these annotations would provide something that no other JIT on the
market can accomplish?

Additionally, these annotations scare me a bit. What if the annotation is
wrong? Does the VM just crash in this case?


>
>
> On the other hand, if Harmony annotations are recognized by the
> community and people start to use them in their application, Harmony
> would gain some benefits. :)


Lets not put the cart before the horse.


>
>
> Thanks,
> xiaofeng
>
> >  -Nathan
> >
> >  On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <xiaofeng.li@gmail.com<https://mail.google.com/mail?view=cm&tf=0&to=xiaofeng.li@gmail.com>>
> wrote:
> >
> >  > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <ndbeyer@apache.org<https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>
> <https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>>
> >
> > > wrote:
> >  > > I know I can be silly at times, but why not focus on making a
> better
> >  > JIT?
> >  >
> >  > Good question... :)  I think the reason is, it's too hard to get the
> >  > JIT to do really well all the time. It's not only because the JIT is
> >  > not smart enough yet, but also because there are tradeoffs between
> >  > compilation time and execution time.
> >  >
> >  > Well, annotation is not the panacea for performance. JIT is still the
> >  > major labor. Annotation is likes that when you are climbing on crag,
> >  > and accidentally find a dent to put your foot. :)
> >  >
> >  > Thanks,
> >  > xiaofeng
> >  >
> >  > >  -Nathan
> >  > >
> >  > >
> >  > >
> >  > >  On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> >  > >  aleksey.shipilev@gmail.com<https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com>
> <https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com>>
> >
> >
> > > wrote:
> >  > >
> >  > >  > Hi,
> >  > >  >
> >  > >  > I had returned to idea to have @Inline and @NoBoundCheck
> annotation
> >  > >  > support in classlib and Jitrino.
> >  > >  > I will try to summarize the rationale for both these
> annotations:
> >  > >  >
> >  > >  >  1. @Inline. There are places where we're creating small methods
> to
> >  > >  > get more consistent code, while we expect JIT should inline them
> to
> >  > >  > reduce call penalty. Unfortunately, this is not always the case
> and
> >  > >  > any JIT can miss the opportunities for inline. As classlib
> developers
> >  > >  > we can dope our code with the hints saying "this method is
> really
> >  > >  > should be inlined, as we know it would be the penalty leaving it
> not
> >  > >  > inlined, just do it even when inline budget is exhausted".
> Jitrino
> >  > >  > really have @Inline already as the part of vmmagic package, but
> I
> >  > want
> >  > >  > to see these annotations visible from the classlib part.
> >  > >  >
> >  > >  > That's the case of new HashMap [1] for example:
> >  > >  >
> >  > >  >    /*
> >  > >  >     * Contract-related functionality
> >  > >  >     */
> >  > >  >    static int computeHashCode(Object key) {
> >  > >  >        return key.hashCode();
> >  > >  >    }
> >  > >  >
> >  > >  >    static boolean areEqualKeys(Object key1, Object key2) {
> >  > >  >        return key1.equals(key2);
> >  > >  >    }
> >  > >  >
> >  > >  >    static boolean areEqualValues(Object value1, Object value2)
{
> >  > >  >        return value1.equals(value2);
> >  > >  >    }
> >  > >  >
> >  > >  >
> >  > >  >  2. @NoBoundCheck. There are also cases in which we definitely
> know
> >  > >  > that no bound check need to be performed. This is the case of
> HashMap
> >  > >  > again:
> >  > >  >
> >  > >  >    ...
> >  > >  >            int hash = computeHashCode(key);
> >  > >  >            index = hash & (elementData.length - 1);
> >  > >  >            entry = elementData[index];
> >  > >  >    ...
> >  > >  >
> >  > >  >   Of course, good JIT compiler should also resolve such patterns
> and
> >  > >  > eliminate bounds check here, but we can again hint the compiler
> they
> >  > >  > are not necessary. There's a complication though that such
> pragma
> >  > >  > could violate security if used in user code, but we could
> restrict
> >  > its
> >  > >  > usage to bootstrap classes only. ABCD gurus (Egor?) could shed
> more
> >  > >  > light whether it's possible to implement on JIT side.
> >  > >  >
> >  > >  > What do you think? I can elaborate with proof-of-concept patches
> to
> >  > >  > see what advantage it would bring.
> >  > >  >
> >  > >  > Thanks,
> >  > >  > Aleksey.
> >  > >  >
> >  > >  > [1] https://issues.apache.org/jira/browse/HARMONY-5791
> >  > >  >
> >  > >
> >  >
> >  >
> >  >
> >  > --
> >  > http://xiao-feng.blogspot.com
> >  >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message