On Sat, Apr 2, 2011 at 5:30 PM, Robert Fischer <[email protected]> wrote: > I've been looking into exactly this kind of problem for my functional > programming language. The sheer amount of megamorphic love that "fold" > receives got me thinking about this. Although there's some work that I > could do at compile time, there's really not terribly much, and I've > been under the impression that this is exactly the kind of situation > which makes life hard on the JVM's runtime optimization. > > The big question is how much room there is for an optimization to > really benefit? How much tracking overhead becomes counter-productive > to optimization?
I think the potential is *very* large. My escape analysis example was only one key case that's impossible to optimize without being able to inline closures. Others may include loop unrolling (JIT can't optimize as well when it doesn't know what a downstream call might do), bounds-check elimination (loops conditional on the closure result, for example), and of course anything related to doing a slow CALL (register allocation, memory optimizations, inline cache or vtable dispatch...). Basically, it forces the body of some iteration into always being a CALL, and all optimizations you'd normally get inside a loop body are impossible. I also want to make clear this affects all languages that pass functions or closure around, including Groovy, JRuby, Scala, Clojure, current Java with callbacks/anon classes, and upcoming Java 7 closure support. - 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.
