On Mon, Apr 28, 2008 at 9:02 PM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 9:13 AM, Nathan Beyer <[EMAIL > PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[EMAIL PROTECTED]>> > 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 <[EMAIL > > PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[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]> > <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]> > <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 > > > > > > > > > -- > http://xiao-feng.blogspot.com >
