harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Mon, 28 Apr 2008 23:58:47 GMT
On Tue, Apr 29, 2008 at 4:00 AM, Sergey Salishev
<sergey.i.salishev@gmail.com> wrote:
> Hi,
>
>  I don't think JAPI would be a problem as the public API method can be turned
>  into a wrapper around private method with @Inline annotation. I think the
>  real problem for Jikes RVM is that adding annotations to the class libraries
>  is the modification of the third party code (GNU classpath) leading to
>  burden of supporting the modifications. The Harmony has slightly different
>  situation as the class libraries are already a part of it.
>
>  As @Inline and @NoBoundsCheck are only intended to be used in class
>  libraries I propose another option: just supply the JIT with the list of the
>  methods for these specific optimisations.
>
>  Nevertheless, I prefer using annotations in the code as it's the most
>  transparent demonstration of intentions.


Annotation is a constant interesting topic. If we really take this
route (code annotation), should we define some standard to categorize
the annotation kind and severity? For example, "inline" in C/C++ has
simple inline and forced inline. And inline is for performance while
bounds checking is for correctness. This hint gives the compiler
options when making tradeoffs.

In my prior work with compiler, a couple of other annotations for
variables could be very useful for performance, such as "thread
local", "recyclable", etc. These are also related to
correctness´╝îshould be applied careful. And it's important for the
programmer to remember the maintenance of the annotations when they
modify the code.

I think we can start from simple ones like inline or bounds checking.
Just leave rooms to extensions.

Thanks,
xiaofeng

>  Thanks,
>  Sergey.
>
>
>
>  On Mon, Apr 28, 2008 at 11:38 PM, Ian Rogers <rogers.email@gmail.com> wrote:
>
>  > 2008/4/28 Tim Ellison <t.p.ellison@gmail.com>:
>  >  >
>  > > Ian Rogers wrote:
>  > >
>  > > > Aleksey Shipilev wrote:
>  > > >
>  > > > > Hi,
>  > > > >
>  > > > > 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
>  > > > > 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.
>  > > > >
>  > > > > 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
>  > > > >
>  > > > >
>  > > > Hi Aleksey,
>  > > >
>  > > > an alternate approach may be to use a bytecode engineering library.
>  > For
>  > > example, Jikes RVM uses ASM to add annotations to the library during
>  > > bootstrap compilation [1].
>  > > >
>  > >
>  > >  Are you advocating using bytecode modification specifically over source
>  > > annotations, or just pointing it out as an alternative?
>  > >
>  > >  Since Harmony has the class library implementation I'm more inclined to
>  > > consider this directly in the source code.
>  > >
>  > >  Regards,
>  > >  Tim
>  >
>  > I'm proposing it as an alternative. For the RVM modifying the Java
>  > files wasn't an option, but I believe even if it were considered it
>  > would have been unpopular as tools like JAPI would have highlighted
>  > the difference of the annotated API with that of the standard class
>  > library.
>  >
>  > Ian
>  > --
>  > Third International Workshop on Implementation, Compilation,
>  > Optimization of Object-Oriented Languages, Programs and Systems
>  > (ICOOOLPS 2008)
>  > Submissions/Notification/Conference: May 4th/May 19th/July 7th
>  > Paphos (Cyprus) http://icoolps.loria.fr
>  >
>  >  > > A few of the other annotations we use are:
>  > > >
>  > > > @Pure to indicate that a method can be called at compile time if its
>  > > arguments are constants. This allows us to turn
>  > > BigInteger.ONE.add(BigInteger.TEN) into a literal BigInteger holding the
>  > > value 11.
>  > > >
>  > > > @NoEscapes indicates that if an aggregate (object or array) is passed
>  > as
>  > > an argument to a method, and this call is the sole reason an aggregate
>  > > escapes, the object can be replaced by scalars. We use this to avoid
>  > stack
>  > > trace generation when the stack trace is never read.
>  > > >
>  > > > Regards,
>  > > > Ian Rogers
>  > > >
>  > > > [1]
>  > >
>  > http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/tools/asm-tasks/src/org/jikesrvm/tools/asm/AnnotationAdder.java?revision=14102&view=markup
>  > > >
>  > >
>  >
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message