On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <[EMAIL PROTECTED]> wrote: > 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?
So far I care mostly about Harmony. If other JIT can do the same thing with Harmony classlib, it would be welcome. > Additionally, these annotations scare me a bit. What if the annotation is > wrong? Does the VM just crash in this case? Valid concern. You can think annotation as part of code. But basically it's only a hint, so much less dangerous than wrong code. If wrong code can cause VM crash, it is possible for annotation as well. Annotation can be completely ignored normally, and only respected when aggressive optimizations are desirable. > > > > > > > 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. Then let's have the horse first. :) Thanks, xiaofeng > > > > > > > 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 > > > -- http://xiao-feng.blogspot.com
