harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Tue, 29 Apr 2008 01:13:52 GMT
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?

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 engergy on more strategic concerns.

-Nathan

On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <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>>
> 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>>
> 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
>

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