On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <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>>
> 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 <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>>
> >
> > > 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>>
> >
> >
> > > 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
>
|