JRuby status

[Rémi Forax]

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