harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Tue, 29 Apr 2008 10:47:20 GMT
On the 0x431 day of Apache Harmony Aleksey Shipilev wrote:
> Hi,
> 
> I had returned to idea to have @Inline and @NoBoundCheck annotation
> support in classlib and Jitrino.

I am not sure how much work it is to do, but I always wanted to have
ways to access annotations in JIT. There are multiple applications for
that always appearing here and there.

so, I am +1 for such mechanism. We can restrict it to just system
classes for the start.

> 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.

As for this specific example the reason JIT is not eating the expr
properly is that it looked like a very rare pattern in
practice. Straightforward solution is: "if a[i] check is proven
redundant then a[i&anything] is redundant". Does it suit you, Alexey?
Any other enhancement ideas?

> 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
> 

-- 
Egor Pasko


Mime
View raw message