On Sun, Aug 28, 2011 at 10:58 AM, Tal Liron <tal.li...@gmail.com> wrote:
> I wonder if it would be that difficult to replace the reflector code with >> an invokedynamic. There is a way to get from a java.lang.reflect.Method to a >> java.lang.invoke.MethodHandle (see >> java.lang.invoke.MethodHandles.Lookup.unreflect). You could probably just >> replace the code that emits a direct call to clojure.lang.Reflector to emit >> an invokedynamic instruction that calls a bootstrap method that wraps the >> Reflector code and just converts the Method into a MethodHandle for >> bootstrapping. >> > > I think you're overstating the problem: reflection is ugly, but it only > happens here during compilation. From then on, the compiled code does what > it needs to do with the types. At least, that's my reading of it: you told > me before that I was dead wrong here, and maybe I am! If I'm right, then I > don't see a "gap" here that invokedynamic can help bridge. > If you look at the links in my previous e-mail (specifically this one https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L1364). The reflection is done in the compiler only when there is a tag (i.e. a type hint). Otherwise the compiler just emits an invoke instruction to call the Reflector at runtime. That invoke could be replaced with an invokedynamic instruction. If you are able to push a branch I may be able to find some time to hack on it. Thanks for sticking with this though. The more I understand about invokedynamic the more interesting it becomes. 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
