harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Tue, 29 Apr 2008 08:12:30 GMT
Xiao-Feng Li wrote:
> 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.

The annotations are classes, so we could imagine having parameters too 
if you want to augment the kind of hint, such as 'forced'.

> And inline is for performance while
> bounds checking is for correctness. This hint gives the compiler
> options when making tradeoffs.

Well, specifying @NoBoundsCheck would also be for performance, but with 
the potential for a side effect of incorrectness.  The code is 
guaranteed correct without any annotation.

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



View raw message