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.

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



More information about the mlvm-dev mailing list