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 Wed, 30 Apr 2008 07:10:29 GMT
On the 0x436 day of Apache Harmony Alexey Varlamov wrote:
> 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...

I did not know :( Thanks for the pointer!

> AFAIU Aleksey just suggests to extend support with richer set of
> annotations and propagate tuning markup to vm-agnostic source codes of
> classlib.

I see. This is good.

P.S.: probably @Inline should not guarantee inlining. Recursive calls
are an example. Do we throw OutOfMemory from inliner correctly?

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

-- 
Egor Pasko


Mime
View raw message