Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
 support
Date: 29 Apr 2008 14:47:20 +0400
Lines: 77
Message-ID: <0vq1w4pkkef.fsf@gmail.com>
References: <4bebff790804250403v1c661d6u5d5b32b0f6283cac@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
Sender: news <news@ger.gmane.org>

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