Bummer. I'd hoped that MethodHandles would allow me to focus on the interpreter rather than having to reinvent the wheel lower down. Doubly so, because your foldArguments combinator has the semantics I want rather than the regular function composition pattern. Sorta like the lambda mess, I'd been really excited by what I'd thought they were doing, rather than what they were actually up to. Oh well.
I really appreciate the time and patience answering my questions, nonetheless. Thanks a bunch. // James MethodHandles were not intended to be used as an intermediary language > for a whole program but just for the dynamic part of one expression that > changed at runtime. > > So in term of performance, one small issue will be the boxing/unboxing > due to the fact that you use an array of Object and that I'm pretty sure > that the JIT will not be able to remove the boxing here. > The other problem is that for complex expressions you will generate a > giant method handle tree, and I'm pretty sure that at some point the JIT > will stop to compile it because it will generate too many SSA nodes. > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To unsubscribe from this group and stop receiving emails from it, send an email to jvm-languages+unsubscr...@googlegroups.com. To post to this group, send email to jvm-languages@googlegroups.com. Visit this group at http://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/groups/opt_out.
