On Thu, Aug 25, 2011 at 6:05 PM, Tal Liron <tal.li...@gmail.com> wrote:
> > Hmm... If you didn't have to worry about Java <7 compatibility, for one >> thing with invokedynamic you could remove a lot of code from Clojure. No >> more IFn or AFn. You simply have a method handle. >> > > Actually, Clojure's solution is almost identical to a method handle. An > instance of AFn is not much different from an instance of MethodHandle, from > the JVM's standpoint. The problem MethodHandle solves for languages like > JRuby is that they need *different classes* for each method handling, > whereas Clojure gets away with instances. Where using MethodHandle becomes > important is when you want to participate in the invokedynamic > bootstrapping, which expects MethodHandle instances. If Clojure ever needs > to do this, it would be a simple one-to-one translation from AFn. > I may be missing something, but I don't see how JRuby needs different classes. If you look at the JRuby code at the most basic level a method on a class is an instance of org.jruby.internal.runtime.methods.* or something else and those classes don't have so much to do with dispatch styles as optimizations. See, JRuby is able to achieve performance that is pretty darn close to Java, while still doing dynamic dispatch (without type hints). Clojure can not even get close to Java performance without type hints. All those different Method classes and all the complex stuff that JRuby does to make *dynamic* dispatch fast now gets pushed down into the JVM, and if Clojure taps into it, we could also get performance for dynamic dispatch that is much closer to Java. One could say, "If you want performance use type hints," and that's a valid opinion, but again it's a different thing. Using type hints you are switching to static dispatch. If you want much better performance for *dynamic* dispatch, if you want much better performance without having to do type hints, then invokedynamic is here to help. Also, there's actually a huge difference between IFn and MethodHandle. When you invoke an IFn you have to cast your arguments into Objects, which for primitives means you have to box them. When you invoke a MethodHandle, this does not happen. You push your primitive arguments onto the stack, then when the invokedynamic instruction is executed the arguments are boxed only if necessary. Same thing with casting objects. You push the raw arguments onto the stack, and at runtime you can do casts, if necessary. IFn is a static, compile-time interface, and when using it you must force your arguments into it's compile-time signature. MethodHandles are not compile-time. Second, I think it would allow the JVM to have a better view into >> optimization, and would allow the JVM to optimize something speculatively >> and allow for Clojure tell the JVM when to deoptimize with a SwitchPoints >> and MutableCallSites. >> > > Except that there's no functional mutability in Clojure! I tried hard, but > I could not come up with a case in which this could be used. What are you > thinking of, specifically? > A function value is immutable in Clojure, but Vars are not. Protocols are not. Multimethods are not. Those are the cases I'm thinking of where you could use SwitchPoints to tell the JVM, "hey, I know you optimized this MethodHandle by inlining all the code, but now the Var has changed (sorry)." Paul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
