On Sun, Apr 3, 2011 at 10:38 AM, Kresten Krab Thorup <[email protected]> wrote: > I would think that this is a case where a vm has a chance to shine. > Your "eachCommon" just needs to be inlined into the callsite, and the > call to yield becomes monomorphic. That's the primary optimization > that makes the JVM run fast.
I'm not sure if you're saying that current JVMs work this way or saying that they should work this way. They don't do this right now. eachCommon's call sites are considered independent of any callers. Because the yield call ends up seeing numerous code bodies, that call site is megamorphic and will never inline anything. eachCommon itself will inline into the caller, but that's as far as it goes since current JVMs do not specialize call sites based on the current method's caller. Of course I'd love to see JVMs be smart enough to specialize call sites based on the caller backtrace. > 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. If we could say "inline the called method as though it were right here and specialize all its call sites based on this method" then this would work. But simply inlining is not enough if call sites are not specialized. - 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.
