You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Aleksey Shipilev <al...@gmail.com> on 2008/04/25 13:03:19 UTC
[classlib][performance] @Inline and @NoBoundsCheck annotation support
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
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Alexey Varlamov <al...@gmail.com>.
2008/4/30, Nathan Beyer <nb...@gmail.com>:
> On Tue, Apr 29, 2008 at 5:47 AM, Egor Pasko <eg...@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
> >
> >
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Nathan Beyer <nb...@gmail.com>.
On Tue, Apr 29, 2008 at 5:47 AM, Egor Pasko <eg...@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.
-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
>
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Aleksey Shipilev <al...@gmail.com>.
Hi
> > > 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.
> >
> > In fact such mechanism is already there and is used for a long, e.g.
> > look for Inliner::processInlinePragmas() in Jitrino.OPT. I thought
> > you're aware of it...
Yep, actually I'm going to extend this existing functionality to
o.a.h.annotations.Inline pragma.
> P.S.: probably @Inline should not guarantee inlining.
Yep, it should not. Actually we have to distinct two types of inline
pragmas: forced inline (that is used in vmmagics) and bonus inline (to
be used as doping for heuristics calculation).
Thanks,
Aleksey.
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x436 day of Apache Harmony Alexey Varlamov wrote:
> 29 Apr 2008 14:47:20 +0400, Egor Pasko <eg...@gmail.com>:
> > 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.
>
> In fact such mechanism is already there and is used for a long, e.g.
> look for Inliner::processInlinePragmas() in Jitrino.OPT. I thought
> you're aware of it...
I did not know :( Thanks for the pointer!
> AFAIU Aleksey just suggests to extend support with richer set of
> annotations and propagate tuning markup to vm-agnostic source codes of
> classlib.
I see. This is good.
P.S.: probably @Inline should not guarantee inlining. Recursive calls
are an example. Do we throw OutOfMemory from inliner correctly?
> > 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
> >
> >
>
--
Egor Pasko
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Alexey Varlamov <al...@gmail.com>.
29 Apr 2008 14:47:20 +0400, Egor Pasko <eg...@gmail.com>:
> 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.
In fact such mechanism is already there and is used for a long, e.g.
look for Inliner::processInlinePragmas() in Jitrino.OPT. I thought
you're aware of it...
AFAIU Aleksey just suggests to extend support with richer set of
annotations and propagate tuning markup to vm-agnostic source codes of
classlib.
>
> 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
>
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Egor Pasko <eg...@gmail.com>.
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.
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
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Sergey Salishev <se...@gmail.com>.
Hi Nathan,
I would partially agree with you on @Inline annotation but @NoBoundsCheck is
a different matter.
1. I think it still makes sense to hand tune class libraries as many user
applications have hot spots in class libraries in particular in collections
and common algorithms.
2. Eliminating bounds checks is a tough and costly optimization as it
requires interval arithmetic to work in nontrivial cases like binary search
in array for example. I don't know about Java JIT doning this type of
optimizations. But using @NoBoundsCheck trivially solves the problem.
Thanks.
Sergey.
On Tue, Apr 29, 2008 at 6:39 AM, Nathan Beyer <nd...@apache.org> wrote:
> On Mon, Apr 28, 2008 at 9:27 PM, Xiao-Feng Li <xi...@gmail.com>
> wrote:
>
> > On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <nbeyer@gmail.com<
> https://mail.google.com/mail?view=cm&tf=0&to=nbeyer@gmail.com>>
> > wrote:
> > > On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <xiaofeng.li@gmail.com<
> https://mail.google.com/mail?view=cm&tf=0&to=xiaofeng.li@gmail.com>>
> > wrote:
> > >
> > >
> > > > On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <ndbeyer@apache.org<
> https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>
> > <ht...@apache.org>>
> > > > wrote:
> > > > > What about non-classlib code? If the JIT isn't going to get any
> > better
> > > > then
> > > > > user code is still going to have inline opportunities missed,
> > correct?
> > > >
> > > > Right. That's something depending on JIT's capability.
> > > >
> > > > > This seems like a tactical approach to get faster JRE code in
> the
> > > > short-term
> > > > > that won't provide any benefit in the long-term. I'd rather
> > advocate
> > > > > spending egnergy on more strategic concerns.
> > > >
> > > > I agree. The problem is, to improve JIT to cover all the important
> > > > cases is, unfortunately in my estimation, a long and huge effort.
> And
> > > > JIT has certain limit, which is always not as smart as human being.
> > We
> > > > can't expect it can improve in short term. I don't mean JIT will
> not
> > > > improve. They are two simultaneous efforts. Putting annotation
> > doesn't
> > > > exclude any JIT improvement efforts.
> > >
> > >
> > > So this these annotations would provide something that no other JIT
> on
> > the
> > > market can accomplish?
> >
> > So far I care mostly about Harmony. If other JIT can do the same thing
> > with Harmony classlib, it would be welcome.
>
>
> But any potential user wouldn't care. Look at it from a consumer's
> perspective. A user isn't going to use a Harmony JIT or Harmony Class
> Library or a Harmony VM -- they're going to use a Harmony JRE. If another
> JRE has a JIT that can perform these optimizations on user code, then
> they'll go with that. Regardless of how much inlining and bounds checking
> you can remove from class library code, it won't make any difference if
> you
> can't do the same on actual application code.
>
> Don't get me wrong, this sounds like an interesting bit of research. I
> just
> hope it doesn't take away from other efforts. It's interesting, but a
> better
> JIT would be cooler.
>
> -Nathan
>
>
> >
> >
> > > Additionally, these annotations scare me a bit. What if the
> annotation
> > is
> > > wrong? Does the VM just crash in this case?
> >
> > Valid concern. You can think annotation as part of code. But basically
> > it's only a hint, so much less dangerous than wrong code. If wrong
> > code can cause VM crash, it is possible for annotation as well.
> > Annotation can be completely ignored normally, and only respected when
> > aggressive optimizations are desirable.
> >
>
> >
> > >
> > > >
> > > >
> > > > On the other hand, if Harmony annotations are recognized by the
> > > > community and people start to use them in their application,
> Harmony
> > > > would gain some benefits. :)
> > >
> > >
> > > Lets not put the cart before the horse.
> >
> > Then let's have the horse first. :)
> >
> > Thanks,
> > xiaofeng
> >
> > >
> > > >
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > > -Nathan
> > > > >
> > > > > On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <
> > xiaofeng.li@gmail.com<
> https://mail.google.com/mail?view=cm&tf=0&to=xiaofeng.li@gmail.com>
> > <ht...@gmail.com>>
> > >
> > >
> > > > wrote:
> > > > >
> > > > > > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <
> > ndbeyer@apache.org<
> https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>
> > <ht...@apache.org>
> > > > <ht...@apache.org>>
> > > > >
> > > > > > wrote:
> > > > > > > I know I can be silly at times, but why not focus on making
> a
> > > > better
> > > > > > JIT?
> > > > > >
> > > > > > Good question... :) I think the reason is, it's too hard to
> get
> > the
> > > > > > JIT to do really well all the time. It's not only because the
> > JIT is
> > > > > > not smart enough yet, but also because there are tradeoffs
> > between
> > > > > > compilation time and execution time.
> > > > > >
> > > > > > Well, annotation is not the panacea for performance. JIT is
> > still the
> > > > > > major labor. Annotation is likes that when you are climbing on
> > crag,
> > > > > > and accidentally find a dent to put your foot. :)
> > > > > >
> > > > > > Thanks,
> > > > > > xiaofeng
> > > > > >
> > > > > > > -Nathan
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > > > > > > aleksey.shipilev@gmail.com<
> https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com>
> > <https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com
> >
> > > > <
> > https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com
> >>
> > > > >
> > > > >
> > > > > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > http://xiao-feng.blogspot.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Apr 29, 2008 at 4:22 PM, Tim Ellison <t....@gmail.com> wrote:
> Aleksey Shipilev wrote:
>
> > Thanks for attention to this topic, guys! That's the point on which
> > JIT and Classlib code interact together: Classlib can provide the
> > hints how to compile it, JIT can favor such hints. While we shipping
> > Harmony JRE I think it makes sense to provide such the hints across
> > the components. Whether or not some other JIT will favor these
> > annotation is completely relies on "that-other-JIT" developers, and we
> > don't really care because it does not break functionality.
> >
>
> Agreed.
>
>
>
> > Let's emphasize that one more time - @NoBoundCheck is unsafe and
> > should be used in trusted code only, there is a clear security breach
> > if such the annotation work for user code. We can imagine a load of
> > other annotations that can't be exposed to user. On the other hand I
> > really doubt that any user code will add the dependency upon internal
> > Harmony annotation for it's own code, e.g.
> > org.apache.harmony.luni.annotations.Inline (ok, I wouldn't do that
> > being Java developer). Should we care about user code and support
> > @Inline pragma originating from any package user wants?
> >
>
> I wouldn't prevent people from adding @Inline to their application methods
> if they choose to do so. But I would prevent @NoBoundsCheck of course for
> any classes not loaded by the bootstrap class loader.
Agree. It's now much clear...
> Regards,
> Tim
>
--
http://xiao-feng.blogspot.com
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
support
Posted by Tim Ellison <t....@gmail.com>.
Aleksey Shipilev wrote:
> On Tue, Apr 29, 2008 at 12:22 PM, Tim Ellison <t....@gmail.com> wrote:
>>> Should we care about user code and support
>>> @Inline pragma originating from any package user wants?
>>>
>> I wouldn't prevent people from adding @Inline to their application methods
>> if they choose to do so. But I would prevent @NoBoundsCheck of course for
>> any classes not loaded by the bootstrap class loader.
>
> I mean here that annotation is a class, presumably will be placed in
> o.a.h.luni.annotations.*. There are two options for us:
> 1. We favor only @Inline annotation coming from
> o.a.h.luni.annotations.*. That's the simplest way but it would require
> for user that wants to use this annotation to import o.a.h package.
I vote for this option, since then there is no ambiguity about what the
annotation means (because we can define it precisely), and we can refine
it with parameters etc as we see fit.
Regards,
Tim
> 2. We can handle all @Inline annotations coming from any package user
> want. Here user may declare it's own annotation in its own package and
> use it. It also would be the generalization point, because we can
> aggregate vmmagic's @Inline annotations here.
>
> Thanks,
> Aleksey.
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Aleksey Shipilev <al...@gmail.com>.
On Tue, Apr 29, 2008 at 12:22 PM, Tim Ellison <t....@gmail.com> wrote:
> > Should we care about user code and support
> > @Inline pragma originating from any package user wants?
> >
>
> I wouldn't prevent people from adding @Inline to their application methods
> if they choose to do so. But I would prevent @NoBoundsCheck of course for
> any classes not loaded by the bootstrap class loader.
I mean here that annotation is a class, presumably will be placed in
o.a.h.luni.annotations.*. There are two options for us:
1. We favor only @Inline annotation coming from
o.a.h.luni.annotations.*. That's the simplest way but it would require
for user that wants to use this annotation to import o.a.h package.
2. We can handle all @Inline annotations coming from any package user
want. Here user may declare it's own annotation in its own package and
use it. It also would be the generalization point, because we can
aggregate vmmagic's @Inline annotations here.
Thanks,
Aleksey.
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
support
Posted by Tim Ellison <t....@gmail.com>.
Aleksey Shipilev wrote:
> Thanks for attention to this topic, guys! That's the point on which
> JIT and Classlib code interact together: Classlib can provide the
> hints how to compile it, JIT can favor such hints. While we shipping
> Harmony JRE I think it makes sense to provide such the hints across
> the components. Whether or not some other JIT will favor these
> annotation is completely relies on "that-other-JIT" developers, and we
> don't really care because it does not break functionality.
Agreed.
> Let's emphasize that one more time - @NoBoundCheck is unsafe and
> should be used in trusted code only, there is a clear security breach
> if such the annotation work for user code. We can imagine a load of
> other annotations that can't be exposed to user. On the other hand I
> really doubt that any user code will add the dependency upon internal
> Harmony annotation for it's own code, e.g.
> org.apache.harmony.luni.annotations.Inline (ok, I wouldn't do that
> being Java developer). Should we care about user code and support
> @Inline pragma originating from any package user wants?
I wouldn't prevent people from adding @Inline to their application
methods if they choose to do so. But I would prevent @NoBoundsCheck of
course for any classes not loaded by the bootstrap class loader.
Regards,
Tim
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Aleksey Shipilev <al...@gmail.com>.
Thanks for attention to this topic, guys! That's the point on which
JIT and Classlib code interact together: Classlib can provide the
hints how to compile it, JIT can favor such hints. While we shipping
Harmony JRE I think it makes sense to provide such the hints across
the components. Whether or not some other JIT will favor these
annotation is completely relies on "that-other-JIT" developers, and we
don't really care because it does not break functionality.
Let's emphasize that one more time - @NoBoundCheck is unsafe and
should be used in trusted code only, there is a clear security breach
if such the annotation work for user code. We can imagine a load of
other annotations that can't be exposed to user. On the other hand I
really doubt that any user code will add the dependency upon internal
Harmony annotation for it's own code, e.g.
org.apache.harmony.luni.annotations.Inline (ok, I wouldn't do that
being Java developer). Should we care about user code and support
@Inline pragma originating from any package user wants?
Thanks,
Aleksey.
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Alexey Varlamov <al...@gmail.com>.
2008/4/29, Xiao-Feng Li <xi...@gmail.com>:
> On Tue, Apr 29, 2008 at 10:39 AM, Nathan Beyer <nd...@apache.org> wrote:
> > On Mon, Apr 28, 2008 at 9:27 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
> >
> > > On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <nb...@gmail.com>>
> > > wrote:
> >
> >
> > > > On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <xi...@gmail.com>>
> > > wrote:
> > > >
> > > >
> > > > > On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <nd...@apache.org>
> > > <ht...@apache.org>>
> > > > > wrote:
> > > > > > What about non-classlib code? If the JIT isn't going to get any
> > > better
> > > > > then
> > > > > > user code is still going to have inline opportunities missed,
> > > correct?
> > > > >
> > > > > Right. That's something depending on JIT's capability.
> > > > >
> > > > > > This seems like a tactical approach to get faster JRE code in the
> > > > > short-term
> > > > > > that won't provide any benefit in the long-term. I'd rather
> > > advocate
> > > > > > spending egnergy on more strategic concerns.
> > > > >
> > > > > I agree. The problem is, to improve JIT to cover all the important
> > > > > cases is, unfortunately in my estimation, a long and huge effort. And
> > > > > JIT has certain limit, which is always not as smart as human being.
> > > We
> > > > > can't expect it can improve in short term. I don't mean JIT will not
> > > > > improve. They are two simultaneous efforts. Putting annotation
> > > doesn't
> > > > > exclude any JIT improvement efforts.
> > > >
> > > >
> > > > So this these annotations would provide something that no other JIT on
> > > the
> > > > market can accomplish?
> > >
> > > So far I care mostly about Harmony. If other JIT can do the same thing
> > > with Harmony classlib, it would be welcome.
> >
> >
> > But any potential user wouldn't care. Look at it from a consumer's
> > perspective. A user isn't going to use a Harmony JIT or Harmony Class
> > Library or a Harmony VM -- they're going to use a Harmony JRE. If another
> > JRE has a JIT that can perform these optimizations on user code, then
> > they'll go with that. Regardless of how much inlining and bounds checking
> > you can remove from class library code, it won't make any difference if you
> > can't do the same on actual application code.
>
> I agree. If JIT can do the same thing as annotation assists, we
> definitely choose JIT approach. In my understanding, there is no
> commercial JIT that is so powerful yet. Harmony JIT still has a long
> way to go, while for these cases, I assume Harmony JIT is not really
> far from other commercial JITs. That's why I think annotation is a
> good complementary.
Right, I don't think improving JIT and fine-tuning classlib code are
mutually competing approaches - so better both be undertaken.
Putting it naively, one may save JIT compilation budget to concentrate
on application code if library code is easier to compile :)
BTW, unlike bootstrapped classlibrary code, correctness-related
annotations should not be respected in user code by default (only if
enabled from command line or via some guarded facility). Just imagine
uncontrolled access to arbitrary memory region opened through
@NoBoundCheck.
Regards,
Alexey
> Actually Java has a couple of JSRs for annotation definitions, though
> not in the same context.
>
> > Don't get me wrong, this sounds like an interesting bit of research. I just
> > hope it doesn't take away from other efforts. It's interesting, but a better
> > JIT would be cooler.
>
> Understood.
>
> Thanks,
> xiaofeng
>
> > -Nathan
> >
> >
> >
> >
> > >
> > >
> > > > Additionally, these annotations scare me a bit. What if the annotation
> > > is
> > > > wrong? Does the VM just crash in this case?
> > >
> > > Valid concern. You can think annotation as part of code. But basically
> > > it's only a hint, so much less dangerous than wrong code. If wrong
> > > code can cause VM crash, it is possible for annotation as well.
> > > Annotation can be completely ignored normally, and only respected when
> > > aggressive optimizations are desirable.
> > >
> >
> > >
> > > >
> > > > >
> > > > >
> > > > > On the other hand, if Harmony annotations are recognized by the
> > > > > community and people start to use them in their application, Harmony
> > > > > would gain some benefits. :)
> > > >
> > > >
> > > > Lets not put the cart before the horse.
> > >
> > > Then let's have the horse first. :)
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > > > > -Nathan
> > > > > >
> > > > > > On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <
> > > xiaofeng.li@gmail.com<ht...@gmail.com>
> > > <ht...@gmail.com>>
> > > >
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <
> > > ndbeyer@apache.org<ht...@apache.org>
> > > <ht...@apache.org>
> > > > > <ht...@apache.org>>
> > > > > >
> > > > > > > wrote:
> > > > > > > > I know I can be silly at times, but why not focus on making a
> > > > > better
> > > > > > > JIT?
> > > > > > >
> > > > > > > Good question... :) I think the reason is, it's too hard to get
> > > the
> > > > > > > JIT to do really well all the time. It's not only because the
> > > JIT is
> > > > > > > not smart enough yet, but also because there are tradeoffs
> > > between
> > > > > > > compilation time and execution time.
> > > > > > >
> > > > > > > Well, annotation is not the panacea for performance. JIT is
> > > still the
> > > > > > > major labor. Annotation is likes that when you are climbing on
> > > crag,
> > > > > > > and accidentally find a dent to put your foot. :)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > xiaofeng
> > > > > > >
> > > > > > > > -Nathan
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > > > > > > > aleksey.shipilev@gmail.com<ht...@gmail.com>
> > > <ht...@gmail.com>
> > > > > <
> > > https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com>>
> > > > > >
> > > > > >
> > > > > > > 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > http://xiao-feng.blogspot.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://xiao-feng.blogspot.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Apr 29, 2008 at 10:39 AM, Nathan Beyer <nd...@apache.org> wrote:
> On Mon, Apr 28, 2008 at 9:27 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> > On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <nb...@gmail.com>>
> > wrote:
>
>
> > > On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <xi...@gmail.com>>
> > wrote:
> > >
> > >
> > > > On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <nd...@apache.org>
> > <ht...@apache.org>>
> > > > wrote:
> > > > > What about non-classlib code? If the JIT isn't going to get any
> > better
> > > > then
> > > > > user code is still going to have inline opportunities missed,
> > correct?
> > > >
> > > > Right. That's something depending on JIT's capability.
> > > >
> > > > > This seems like a tactical approach to get faster JRE code in the
> > > > short-term
> > > > > that won't provide any benefit in the long-term. I'd rather
> > advocate
> > > > > spending egnergy on more strategic concerns.
> > > >
> > > > I agree. The problem is, to improve JIT to cover all the important
> > > > cases is, unfortunately in my estimation, a long and huge effort. And
> > > > JIT has certain limit, which is always not as smart as human being.
> > We
> > > > can't expect it can improve in short term. I don't mean JIT will not
> > > > improve. They are two simultaneous efforts. Putting annotation
> > doesn't
> > > > exclude any JIT improvement efforts.
> > >
> > >
> > > So this these annotations would provide something that no other JIT on
> > the
> > > market can accomplish?
> >
> > So far I care mostly about Harmony. If other JIT can do the same thing
> > with Harmony classlib, it would be welcome.
>
>
> But any potential user wouldn't care. Look at it from a consumer's
> perspective. A user isn't going to use a Harmony JIT or Harmony Class
> Library or a Harmony VM -- they're going to use a Harmony JRE. If another
> JRE has a JIT that can perform these optimizations on user code, then
> they'll go with that. Regardless of how much inlining and bounds checking
> you can remove from class library code, it won't make any difference if you
> can't do the same on actual application code.
I agree. If JIT can do the same thing as annotation assists, we
definitely choose JIT approach. In my understanding, there is no
commercial JIT that is so powerful yet. Harmony JIT still has a long
way to go, while for these cases, I assume Harmony JIT is not really
far from other commercial JITs. That's why I think annotation is a
good complementary.
Actually Java has a couple of JSRs for annotation definitions, though
not in the same context.
> Don't get me wrong, this sounds like an interesting bit of research. I just
> hope it doesn't take away from other efforts. It's interesting, but a better
> JIT would be cooler.
Understood.
Thanks,
xiaofeng
> -Nathan
>
>
>
>
> >
> >
> > > Additionally, these annotations scare me a bit. What if the annotation
> > is
> > > wrong? Does the VM just crash in this case?
> >
> > Valid concern. You can think annotation as part of code. But basically
> > it's only a hint, so much less dangerous than wrong code. If wrong
> > code can cause VM crash, it is possible for annotation as well.
> > Annotation can be completely ignored normally, and only respected when
> > aggressive optimizations are desirable.
> >
>
> >
> > >
> > > >
> > > >
> > > > On the other hand, if Harmony annotations are recognized by the
> > > > community and people start to use them in their application, Harmony
> > > > would gain some benefits. :)
> > >
> > >
> > > Lets not put the cart before the horse.
> >
> > Then let's have the horse first. :)
> >
> > Thanks,
> > xiaofeng
> >
> > >
> > > >
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > > -Nathan
> > > > >
> > > > > On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <
> > xiaofeng.li@gmail.com<ht...@gmail.com>
> > <ht...@gmail.com>>
> > >
> > >
> > > > wrote:
> > > > >
> > > > > > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <
> > ndbeyer@apache.org<ht...@apache.org>
> > <ht...@apache.org>
> > > > <ht...@apache.org>>
> > > > >
> > > > > > wrote:
> > > > > > > I know I can be silly at times, but why not focus on making a
> > > > better
> > > > > > JIT?
> > > > > >
> > > > > > Good question... :) I think the reason is, it's too hard to get
> > the
> > > > > > JIT to do really well all the time. It's not only because the
> > JIT is
> > > > > > not smart enough yet, but also because there are tradeoffs
> > between
> > > > > > compilation time and execution time.
> > > > > >
> > > > > > Well, annotation is not the panacea for performance. JIT is
> > still the
> > > > > > major labor. Annotation is likes that when you are climbing on
> > crag,
> > > > > > and accidentally find a dent to put your foot. :)
> > > > > >
> > > > > > Thanks,
> > > > > > xiaofeng
> > > > > >
> > > > > > > -Nathan
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > > > > > > aleksey.shipilev@gmail.com<ht...@gmail.com>
> > <ht...@gmail.com>
> > > > <
> > https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com>>
> > > > >
> > > > >
> > > > > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > http://xiao-feng.blogspot.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Nathan Beyer <nd...@apache.org>.
On Mon, Apr 28, 2008 at 9:27 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
> On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <nb...@gmail.com>>
> wrote:
> > On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <xi...@gmail.com>>
> wrote:
> >
> >
> > > On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <nd...@apache.org>
> <ht...@apache.org>>
> > > wrote:
> > > > What about non-classlib code? If the JIT isn't going to get any
> better
> > > then
> > > > user code is still going to have inline opportunities missed,
> correct?
> > >
> > > Right. That's something depending on JIT's capability.
> > >
> > > > This seems like a tactical approach to get faster JRE code in the
> > > short-term
> > > > that won't provide any benefit in the long-term. I'd rather
> advocate
> > > > spending egnergy on more strategic concerns.
> > >
> > > I agree. The problem is, to improve JIT to cover all the important
> > > cases is, unfortunately in my estimation, a long and huge effort. And
> > > JIT has certain limit, which is always not as smart as human being.
> We
> > > can't expect it can improve in short term. I don't mean JIT will not
> > > improve. They are two simultaneous efforts. Putting annotation
> doesn't
> > > exclude any JIT improvement efforts.
> >
> >
> > So this these annotations would provide something that no other JIT on
> the
> > market can accomplish?
>
> So far I care mostly about Harmony. If other JIT can do the same thing
> with Harmony classlib, it would be welcome.
But any potential user wouldn't care. Look at it from a consumer's
perspective. A user isn't going to use a Harmony JIT or Harmony Class
Library or a Harmony VM -- they're going to use a Harmony JRE. If another
JRE has a JIT that can perform these optimizations on user code, then
they'll go with that. Regardless of how much inlining and bounds checking
you can remove from class library code, it won't make any difference if you
can't do the same on actual application code.
Don't get me wrong, this sounds like an interesting bit of research. I just
hope it doesn't take away from other efforts. It's interesting, but a better
JIT would be cooler.
-Nathan
>
>
> > Additionally, these annotations scare me a bit. What if the annotation
> is
> > wrong? Does the VM just crash in this case?
>
> Valid concern. You can think annotation as part of code. But basically
> it's only a hint, so much less dangerous than wrong code. If wrong
> code can cause VM crash, it is possible for annotation as well.
> Annotation can be completely ignored normally, and only respected when
> aggressive optimizations are desirable.
>
>
> >
> > >
> > >
> > > On the other hand, if Harmony annotations are recognized by the
> > > community and people start to use them in their application, Harmony
> > > would gain some benefits. :)
> >
> >
> > Lets not put the cart before the horse.
>
> Then let's have the horse first. :)
>
> Thanks,
> xiaofeng
>
> >
> > >
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > > -Nathan
> > > >
> > > > On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <
> xiaofeng.li@gmail.com<ht...@gmail.com>
> <ht...@gmail.com>>
> >
> >
> > > wrote:
> > > >
> > > > > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <
> ndbeyer@apache.org<ht...@apache.org>
> <ht...@apache.org>
> > > <ht...@apache.org>>
> > > >
> > > > > wrote:
> > > > > > I know I can be silly at times, but why not focus on making a
> > > better
> > > > > JIT?
> > > > >
> > > > > Good question... :) I think the reason is, it's too hard to get
> the
> > > > > JIT to do really well all the time. It's not only because the
> JIT is
> > > > > not smart enough yet, but also because there are tradeoffs
> between
> > > > > compilation time and execution time.
> > > > >
> > > > > Well, annotation is not the panacea for performance. JIT is
> still the
> > > > > major labor. Annotation is likes that when you are climbing on
> crag,
> > > > > and accidentally find a dent to put your foot. :)
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > > > > -Nathan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > > > > > aleksey.shipilev@gmail.com<ht...@gmail.com>
> <ht...@gmail.com>
> > > <
> https://mail.google.com/mail?view=cm&tf=0&to=aleksey.shipilev@gmail.com>>
> > > >
> > > >
> > > > > 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
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://xiao-feng.blogspot.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
support
Posted by Tim Ellison <t....@gmail.com>.
Xiao-Feng Li wrote:
> On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <nb...@gmail.com> wrote:
>> Additionally, these annotations scare me a bit. What if the annotation is
>> wrong? Does the VM just crash in this case?
>
> Valid concern. You can think annotation as part of code. But basically
> it's only a hint, so much less dangerous than wrong code.
The JIT is free to ignore the hint, in which case you get regular rules
applied, but if the hint is taken it can be more dangerous than wrong
Java code -- though not so wrong native code I agree.
> If wrong code can cause VM crash, it is possible for annotation as
> well. Annotation can be completely ignored normally, and only
> respected when aggressive optimizations are desirable.
With these annotations it is possible to get new and creative ways to
crash too :-) Class library developers will have to understand the
annotations and ensure they are maintained alongside the body of the
method so that they still hold true. They are real code, not just hints
to the class library developer.
Regards,
Tim
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <nb...@gmail.com> wrote:
> On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
>
>
> > On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <nd...@apache.org>>
> > wrote:
> > > What about non-classlib code? If the JIT isn't going to get any better
> > then
> > > user code is still going to have inline opportunities missed, correct?
> >
> > Right. That's something depending on JIT's capability.
> >
> > > This seems like a tactical approach to get faster JRE code in the
> > short-term
> > > that won't provide any benefit in the long-term. I'd rather advocate
> > > spending egnergy on more strategic concerns.
> >
> > I agree. The problem is, to improve JIT to cover all the important
> > cases is, unfortunately in my estimation, a long and huge effort. And
> > JIT has certain limit, which is always not as smart as human being. We
> > can't expect it can improve in short term. I don't mean JIT will not
> > improve. They are two simultaneous efforts. Putting annotation doesn't
> > exclude any JIT improvement efforts.
>
>
> So this these annotations would provide something that no other JIT on the
> market can accomplish?
So far I care mostly about Harmony. If other JIT can do the same thing
with Harmony classlib, it would be welcome.
> Additionally, these annotations scare me a bit. What if the annotation is
> wrong? Does the VM just crash in this case?
Valid concern. You can think annotation as part of code. But basically
it's only a hint, so much less dangerous than wrong code. If wrong
code can cause VM crash, it is possible for annotation as well.
Annotation can be completely ignored normally, and only respected when
aggressive optimizations are desirable.
>
> >
> >
> > On the other hand, if Harmony annotations are recognized by the
> > community and people start to use them in their application, Harmony
> > would gain some benefits. :)
>
>
> Lets not put the cart before the horse.
Then let's have the horse first. :)
Thanks,
xiaofeng
>
> >
> >
> > Thanks,
> > xiaofeng
> >
> > > -Nathan
> > >
> > > On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <xi...@gmail.com>>
>
>
> > wrote:
> > >
> > > > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <nd...@apache.org>
> > <ht...@apache.org>>
> > >
> > > > wrote:
> > > > > I know I can be silly at times, but why not focus on making a
> > better
> > > > JIT?
> > > >
> > > > Good question... :) I think the reason is, it's too hard to get the
> > > > JIT to do really well all the time. It's not only because the JIT is
> > > > not smart enough yet, but also because there are tradeoffs between
> > > > compilation time and execution time.
> > > >
> > > > Well, annotation is not the panacea for performance. JIT is still the
> > > > major labor. Annotation is likes that when you are climbing on crag,
> > > > and accidentally find a dent to put your foot. :)
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > > -Nathan
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > > > > aleksey.shipilev@gmail.com<ht...@gmail.com>
> > <ht...@gmail.com>>
> > >
> > >
> > > > 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
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Nathan Beyer <nb...@gmail.com>.
On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
> On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <nd...@apache.org>>
> wrote:
> > What about non-classlib code? If the JIT isn't going to get any better
> then
> > user code is still going to have inline opportunities missed, correct?
>
> Right. That's something depending on JIT's capability.
>
> > This seems like a tactical approach to get faster JRE code in the
> short-term
> > that won't provide any benefit in the long-term. I'd rather advocate
> > spending egnergy on more strategic concerns.
>
> I agree. The problem is, to improve JIT to cover all the important
> cases is, unfortunately in my estimation, a long and huge effort. And
> JIT has certain limit, which is always not as smart as human being. We
> can't expect it can improve in short term. I don't mean JIT will not
> improve. They are two simultaneous efforts. Putting annotation doesn't
> exclude any JIT improvement efforts.
So this these annotations would provide something that no other JIT on the
market can accomplish?
Additionally, these annotations scare me a bit. What if the annotation is
wrong? Does the VM just crash in this case?
>
>
> On the other hand, if Harmony annotations are recognized by the
> community and people start to use them in their application, Harmony
> would gain some benefits. :)
Lets not put the cart before the horse.
>
>
> Thanks,
> xiaofeng
>
> > -Nathan
> >
> > On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <xi...@gmail.com>>
> wrote:
> >
> > > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <nd...@apache.org>
> <ht...@apache.org>>
> >
> > > wrote:
> > > > I know I can be silly at times, but why not focus on making a
> better
> > > JIT?
> > >
> > > Good question... :) I think the reason is, it's too hard to get the
> > > JIT to do really well all the time. It's not only because the JIT is
> > > not smart enough yet, but also because there are tradeoffs between
> > > compilation time and execution time.
> > >
> > > Well, annotation is not the panacea for performance. JIT is still the
> > > major labor. Annotation is likes that when you are climbing on crag,
> > > and accidentally find a dent to put your foot. :)
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > > -Nathan
> > > >
> > > >
> > > >
> > > > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > > > aleksey.shipilev@gmail.com<ht...@gmail.com>
> <ht...@gmail.com>>
> >
> >
> > > 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
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <nd...@apache.org> wrote:
> What about non-classlib code? If the JIT isn't going to get any better then
> user code is still going to have inline opportunities missed, correct?
Right. That's something depending on JIT's capability.
> This seems like a tactical approach to get faster JRE code in the short-term
> that won't provide any benefit in the long-term. I'd rather advocate
> spending egnergy on more strategic concerns.
I agree. The problem is, to improve JIT to cover all the important
cases is, unfortunately in my estimation, a long and huge effort. And
JIT has certain limit, which is always not as smart as human being. We
can't expect it can improve in short term. I don't mean JIT will not
improve. They are two simultaneous efforts. Putting annotation doesn't
exclude any JIT improvement efforts.
On the other hand, if Harmony annotations are recognized by the
community and people start to use them in their application, Harmony
would gain some benefits. :)
Thanks,
xiaofeng
> -Nathan
>
> On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <nd...@apache.org>>
>
> > wrote:
> > > I know I can be silly at times, but why not focus on making a better
> > JIT?
> >
> > Good question... :) I think the reason is, it's too hard to get the
> > JIT to do really well all the time. It's not only because the JIT is
> > not smart enough yet, but also because there are tradeoffs between
> > compilation time and execution time.
> >
> > Well, annotation is not the panacea for performance. JIT is still the
> > major labor. Annotation is likes that when you are climbing on crag,
> > and accidentally find a dent to put your foot. :)
> >
> > Thanks,
> > xiaofeng
> >
> > > -Nathan
> > >
> > >
> > >
> > > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > > aleksey.shipilev@gmail.com<ht...@gmail.com>>
>
>
> > 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
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Nathan Beyer <nd...@apache.org>.
What about non-classlib code? If the JIT isn't going to get any better then
user code is still going to have inline opportunities missed, correct?
This seems like a tactical approach to get faster JRE code in the short-term
that won't provide any benefit in the long-term. I'd rather advocate
spending engergy on more strategic concerns.
-Nathan
On Mon, Apr 28, 2008 at 8:03 PM, Xiao-Feng Li <xi...@gmail.com> wrote:
> On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <nd...@apache.org>>
> wrote:
> > I know I can be silly at times, but why not focus on making a better
> JIT?
>
> Good question... :) I think the reason is, it's too hard to get the
> JIT to do really well all the time. It's not only because the JIT is
> not smart enough yet, but also because there are tradeoffs between
> compilation time and execution time.
>
> Well, annotation is not the panacea for performance. JIT is still the
> major labor. Annotation is likes that when you are climbing on crag,
> and accidentally find a dent to put your foot. :)
>
> Thanks,
> xiaofeng
>
> > -Nathan
> >
> >
> >
> > On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> > aleksey.shipilev@gmail.com<ht...@gmail.com>>
> 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
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <nd...@apache.org> wrote:
> I know I can be silly at times, but why not focus on making a better JIT?
Good question... :) I think the reason is, it's too hard to get the
JIT to do really well all the time. It's not only because the JIT is
not smart enough yet, but also because there are tradeoffs between
compilation time and execution time.
Well, annotation is not the panacea for performance. JIT is still the
major labor. Annotation is likes that when you are climbing on crag,
and accidentally find a dent to put your foot. :)
Thanks,
xiaofeng
> -Nathan
>
>
>
> On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
> aleksey.shipilev@gmail.com> 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
> >
>
--
http://xiao-feng.blogspot.com
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Nathan Beyer <nd...@apache.org>.
I know I can be silly at times, but why not focus on making a better JIT?
-Nathan
On Fri, Apr 25, 2008 at 6:03 AM, Aleksey Shipilev <
aleksey.shipilev@gmail.com> 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
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Xiao-Feng Li <xi...@gmail.com>.
2008/4/30 Ian Rogers <ro...@gmail.com>:
> Xiao-Feng Li wrote:
> > 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
> >
> Hi,
>
> for the Jikes RVM we found that an important factor was to scale the
> inlining weight with respect to whether parameters were constant or not.
> You can see the When extension to the Inline pragma here:
Thanks, Ian, it's enlightening!
Thanks,
xiaofeng
> http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/vmmagic/src/org/vmmagic/pragma/Inline.java?revision=14020&view=markup
>
> Regards,
>
>
> 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
>
--
http://xiao-feng.blogspot.com
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
support
Posted by Ian Rogers <ro...@gmail.com>.
Xiao-Feng Li wrote:
> 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
>
Hi,
for the Jikes RVM we found that an important factor was to scale the
inlining weight with respect to whether parameters were constant or not.
You can see the When extension to the Inline pragma here:
http://jikesrvm.svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/vmmagic/src/org/vmmagic/pragma/Inline.java?revision=14020&view=markup
Regards,
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
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
support
Posted by Tim Ellison <t....@gmail.com>.
Xiao-Feng Li wrote:
> On Tue, Apr 29, 2008 at 4:00 AM, Sergey Salishev
> <se...@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.
Agreed.
Regards,
Tim
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Apr 29, 2008 at 4:00 AM, Sergey Salishev
<se...@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 <ro...@gmail.com> wrote:
>
> > 2008/4/28 Tim Ellison <t....@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
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Sergey Salishev <se...@gmail.com>.
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.
Thanks,
Sergey.
On Mon, Apr 28, 2008 at 11:38 PM, Ian Rogers <ro...@gmail.com> wrote:
> 2008/4/28 Tim Ellison <t....@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
> > >
> >
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Posted by Ian Rogers <ro...@gmail.com>.
2008/4/28 Tim Ellison <t....@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
> >
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
support
Posted by Tim Ellison <t....@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
> 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
>
Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
support
Posted by Ian Rogers <ro...@gmail.com>.
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]. 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
--
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