Combining more handle types in JRuby
Charles Oliver Nutter
charles.nutter at sun.com
Wed May 27 20:21:00 PDT 2009
Here's a non-working mock-up of some code I'm working on.
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
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.
More information about the mlvm-dev