harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Fri, 25 Apr 2008 11:03:19 GMT

I had returned to idea to have @Inline and @NoBoundCheck annotation
support in classlib and Jitrino.
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

            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.

What do you think? I can elaborate with proof-of-concept patches to
see what advantage it would bring.


[1] https://issues.apache.org/jira/browse/HARMONY-5791

View raw message