Charles Oliver Nutter a écrit : > I thought I'd update all on the progress of indy integration in JRuby. > > Yesterday I worked through almost all the remaining non-handle calls > in the fast path for JRuby dyncalls, replacing them with adapter > handles of various shapes and sizes. The general sequence for a simple > call now uses drop, fold, permute, convert, and insert at various > stages,
It will be a great test case :) > ultimately going directly into our DynamicMethod handle. With > this in place, there's no hand-written JRuby code anywhere in the > sequence, provided that it's a generated DynamicMethod handle. Here's > a backtrace of a fast path call from a closure to "foo" to "bar": > > from -e:1:in `method__1$RUBY$bar' > from __dash_e__#bar:-1:in `call' > from __dash_e__#bar:-1:in `call' > from FilterGeneric.java:845:in `invoke_F7' > from FilterGeneric.java:759:in `invoke_F6' > from MethodHandleImpl.java:614:in `invoke_L5' > from -e:1:in `method__0$RUBY$foo' > from __dash_e__#foo:-1:in `call' > from __dash_e__#foo:-1:in `call' > from FilterGeneric.java:845:in `invoke_F7' > from FilterGeneric.java:759:in `invoke_F6' > from MethodHandleImpl.java:614:in `invoke_L5' > from -e:1:in `block_0$RUBY$__block__' > > The methods "block_0$RUBY$__block__" and "method__0$RUBY$foo" and > "method__1$RUBY$bar" are the actual compiled bodies with mangled > names. The lines with # in them are generated handles pointing at > "bar" and "foo". And everything else in this trace is MethodHandle > logic. > > Remaining steps for this trace are pretty obvious: > > 1. Get our generate handle out of the way, if possible and useful. > There's a bit more pre/post logic there we'd need to represent > somehow, but it's mostly spread/collect and arity-checking logic, all > doable through adapters. > 2. Get the adapter handles out of the way. That will obviously be > necessary to get things to inline all the way through from dyncall to > dyncall. > > There's one remaining step for calls that receive a block as well: > > 1. Wrap in an exception-handling adapter to deal with non-local flow > control logic. > > It's all lining up really nicely so far, though the mental gymnastics > of composing many layers of handles has been a challenge. My strategy > has been to keep comments next to my code showing what the expected > backtrace will be at each step, such as in this version for a simple > one-argument call: http://gist.github.com/139695 > I've just noticed that you can aggregate the two calls to dropArguments into one with two object classes. > This is all committed to JRuby master and can build with or without > MLVM present. > I've forget to say that the backport contains a script that automatically create a mocked jar from mlvm repository : http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport/mock > - Charlie > Rémi _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
