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 03:02:55 GMT
2008/4/30, Nathan Beyer <nbeyer@gmail.com>:
> On Tue, Apr 29, 2008 at 5:47 AM, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> > 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.
>
>
> Assuming these annotations have a retention policy of at least 'class', they
> are just part of the class file, which I would assume the JIT has direct
> access to.
It depends on VM design and impl: JIT has no direct business with
class data representation (other than bytecode) and normally would
only query the rest of VM for class properties.
Further, depending on retention policy of a particular annotation,
Java compiler embeds it to classfile either as
RuntimeVisibleAnnotations or RuntimeInvisibleAnnotation attribute. As
long as spec does not require VM to honor the last one (unless
specifically directed, e.g. with -Xinvisible cmdine switch),  it is up
to VM whether to keep or ignore such annotations. Currently DRLVM
skips invisible annotations by default (for greater efficiency).
I guess the Inline pragma referred by Ian has runtime retention policy
for similar reasons.

Yet this behaviour is easy to tweak if we have good reasons, e.g. to
hide our impl-specific annotations from end users (which I doubt).

Thanks,
Alexey
>
> -Nathan
>
>
> >
> >
> > 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