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 xiaofeng.li@gmail.com
 designates 74.125.46.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nVu87bWQ3f4jjXSzvDhoxqZLS/sR9IrAb/9GkX5SeIQK/lG2hxpSdyRP5RyhKvhAJuaeesrXpbqvfwarvUtVtgyXD5XsNLwiMA/TPXE0XScSBw+VxTBcRNbgo1ad5pLSlHBsTWXjY4vky8p9pqZGB2RvUtDRq0XTVeiCEYjA3IE=
Message-ID: <9623c9a50804281902s1a17175ehc0ad2a2e5770be85@mail.gmail.com>
Date: Tue, 29 Apr 2008 10:02:42 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
 support
In-Reply-To: <3b3f27c60804281813p7dc08af1r5746cb35b4b1a4b1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4bebff790804250403v1c661d6u5d5b32b0f6283cac@mail.gmail.com>
	 <3b3f27c60804281703h73bff889r442c576343b88ee0@mail.gmail.com>
	 <9623c9a50804281803s6ecbe528m46779d6f0cc0414f@mail.gmail.com>
	 <3b3f27c60804281813p7dc08af1r5746cb35b4b1a4b1@mail.gmail.com>

On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <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.

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


-- 
http://xiao-feng.blogspot.com