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 00:03:58 GMT
I know I can be silly at times, but why not focus on making a better JIT?

-Nathan

On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
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
>

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