Here's a non-working mock-up of some code I'm working on. http://gist.github.com/119060
In order to get the best perf out of method handles and indy, we will ideally want only primitive handles all the way from the call site to the target method. In order to do this, we must decompose the call protocol (all the logic in between the call site and the target) into a series of handles. The goal with this code is to take the Java-based fast-path target code from my previous version (current version on jruby invokedynamic branch), and decompose it entirely into hand-written (Java) leaf methods and primitive method handles. The above pastie shows how that would fit together, if all the necessary method handles were functional (they are not at the moment). Specifically, notice that there is no longer a "target" method given to guardWithTest; the fast path of gWT is now tied into a MethodHandle chain leading directly to JRuby's DynamicMethod class, our version of a MethodHandle. I started wiring together a simple DSL in Java to process handle compositions, since it was hurting my brain trying to think about them in reverse. This simple framework queues up those adaptations in sequence (human order), and then when applied to an actual handle it plays them back in reverse (indy order). This makes it easier to picture how the transformations are affecting an incoming argument set. Pay special attention to createGWT, which uses the DSL heavily to assemble several primitive MH adaptations into the test, target, and fallback components of a guardWithTest. I'm hoping to actually make this work once the handles are available, and I'm looking for feeback on it. - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
