harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Wed, 30 Apr 2008 02:31:33 GMT
29 Apr 2008 14:47:20 +0400, Egor Pasko <egor.pasko@gmail.com>:
> 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.

In fact such mechanism is already there and is used for a long, e.g.
look for Inliner::processInlinePragmas() in Jitrino.OPT. I thought
you're aware of it...
AFAIU Aleksey just suggests to extend support with richer set of
annotations and propagate tuning markup to vm-agnostic source codes of
classlib.

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