On Sun, Aug 28, 2011 at 10:25 AM, Tal Liron <tal.li...@gmail.com> wrote:
> Progress! > > I am staring right now at my JVM 7 build of Clojure that uses invokedynamic > for Vars that contain functions. It essentially works, well enough for > experimentation. A few of my simple apps seem to work fine with it. > > There are still a lot of problems: the Clojure test suite fails, and my > re-linking fallback mechanism (based on SwitchPoint) does not differentiate > between root bindings of Var and their "box" thread-binding, so in theory > any rebinding will cause all linkages on that Var to reset. Not very > optimal. > > I've really done very little optimizing at all at this point: invokedynamic > is just replacing the usual invokeinterface. So, I was surprised that when > fooling around with some benchmarks, one of them showed about 30% > performance improvement on one of my Clojure-built web servers. Tantalizing! > But, until the test suite succeeds, I can't be sure that this isn't a side > effect of something not so great that's going on. > > I'm hoping to have something the rest of you can play with soon, but > thought you would want to hear a progress report. What would be the most > convenient way to share this? A dump to github of the whole tree? A patch? > Hey that's good news! It would be simple enough for you to push a branch to your own fork of Clojure on github. > I've used the Clojure 1.2.1 codebase, because I didn't want to work on a > moving target, and also think it might be easier for the community to help > test this with existing applications. (As I said earlier, I also have a few > ideas on how to make sure we can have this mechanism gracefully downgrade to > JVM <7.) > > Many thanks to Paul Stadig and Charlie Nutter for prodding me to realize > that the one point where invokedynamic can help is to bridge the gap between > dereferencing the Var and then calling invokeinterface on it. My mistake > when looking at this the first time around was assuming that the > dereferencing and subsequent invokeinterface were fast operations, and that > it would make little difference to replace them with invokedynamic. But, > speed is not the issue here: it's that this gap represents a black hole for > HotSpot, around which it can't optimize well. Because this mechanism > represents the primary junction for all of Clojure, optimization here could > enable some nifty optimization across the board. I think it's a good way to > imagine invokedynamic's benefits: it's a bridge over troubled water for > HotSpot. > > Paul also points out areas where MethodHandles can replace the rather > sticky reflection work that Clojure does now to massage calls to non-Clojure > libraries. That's not entirely related to the invokedynamic stuff I'm > working on, so I think I'll leave it to somebody else to take a stab at > that... > 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. But things always seem easier until you actually get into them. :) 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
