harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rogers <rogers.em...@gmail.com>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Sun, 27 Apr 2008 15:09:23 GMT
Aleksey Shipilev 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
Hi Aleksey,

an alternate approach may be to use a bytecode engineering library. For 
example, Jikes RVM uses ASM to add annotations to the library during 
bootstrap compilation [1]. A few of the other annotations we use are:

@Pure to indicate that a method can be called at compile time if its 
arguments are constants. This allows us to turn 
BigInteger.ONE.add(BigInteger.TEN) into a literal BigInteger holding the 
value 11.

@NoEscapes indicates that if an aggregate (object or array) is passed as 
an argument to a method, and this call is the sole reason an aggregate 
escapes, the object can be replaced by scalars. We use this to avoid 
stack trace generation when the stack trace is never read.

Ian Rogers

Third International Workshop on Implementation, Compilation, 
Optimization of Object-Oriented Languages, Programs and Systems 
Submissions/Notification/Conference: May 4th/May 19th/July 7th
Paphos (Cyprus) http://icoolps.loria.fr

View raw message