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 <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 8:03 AM, Nathan Beyer <[EMAIL > PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[EMAIL PROTECTED]>> > 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 < > > [EMAIL PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[EMAIL > > PROTECTED]>> > 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 >
