harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib][performance] @Inline and @NoBoundsCheck annotation support
Date Tue, 29 Apr 2008 06:17:13 GMT
2008/4/29, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> On Tue, Apr 29, 2008 at 10:39 AM, Nathan Beyer <ndbeyer@apache.org> wrote:
> > On Mon, Apr 28, 2008 at 9:27 PM, Xiao-Feng Li <xiaofeng.li@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>
> >  > <https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@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<https://mail.google.com/mail?view=cm&tf=0&to=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 8:03 AM, Nathan Beyer <
> >  > ndbeyer@apache.org<https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>
> >  > <https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@apache.org>
> >  > >  > <https://mail.google.com/mail?view=cm&tf=0&to=ndbeyer@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
> >  >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>

Mime
View raw message