Xiao-Feng Li wrote:
On Tue, Apr 29, 2008 at 4:00 AM, Sergey Salishev
<[EMAIL PROTECTED]> 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.
Agreed.
Regards,
Tim
