On Sun, Apr 3, 2011 at 5:04 PM, Jochen Theodorou <[email protected]> wrote: > Am 03.04.2011 17:38, schrieb Kresten Krab Thorup: >> >> So. If method handles or something else disables this optimization, or >> makes it more expensive then perhaps we should consider adding a hint/ >> annotation to the vm saying "it may make sense to inline this". but I >> would think that that is exactly the kind of assessment that the vm >> can do better than static knowledge allows. > > I am wondering... in what case does it *not* make sense to inline? I mean I > can imagine reasons like certain limitations, but in the end... Does anyone > know?
There's the black art of runtime optimization :) I actually reported a performance bug in invokedynamic a couple weeks back that turned out to be Hotspot inlining the *wrong* logic. Basically, it was inlining recursive calls to fib as far as possible without inlining the other calls made in fib that were actually more expensive (and more valuable to inline and optimize. Indeed, the question of what *not* to inline is at least as important as the question of what *to* inline. As a rule of thumb I suppose I'd say you want to inline methods that have the best cost/size ratio; basically, inline the smallest, hottest methods first. I'd love to hear from the JVM vendors what rules their compilers follow, though (and whether there are papers the rest of us could read to understand them better). - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
