Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of nbeyer@gmail.com designates
 74.125.46.158 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=lwAd36Adn7BxFEx77VIWWk5mpl3iZ4IcTXeyD4erwg2WugNkaC73CMnkGM+nSh7w/SiBXZ31d45AdGAGKjqXKLSBXggU5mBHeTASEyv4eMQSB+izh/yOTAeJMPgJmRzQLUkjV2rR7y33FTgx4QIsx+XRkk4xgYuSJMp+XuA1/9g=
Message-ID: <3b3f27c60804281813p7dc08af1r5746cb35b4b1a4b1@mail.gmail.com>
Date: Mon, 28 Apr 2008 20:13:52 -0500
From: "Nathan Beyer" <ndbeyer@apache.org>
Sender: nbeyer@gmail.com
To: dev@harmony.apache.org
Subject: Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
 support
In-Reply-To: <9623c9a50804281803s6ecbe528m46779d6f0cc0414f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9870_16724561.1209431632121"
References: <4bebff790804250403v1c661d6u5d5b32b0f6283cac@mail.gmail.com>
	 <3b3f27c60804281703h73bff889r442c576343b88ee0@mail.gmail.com>
	 <9623c9a50804281803s6ecbe528m46779d6f0cc0414f@mail.gmail.com>

------=_Part_9870_16724561.1209431632121
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_9870_16724561.1209431632121--