Trying to work newer indy into JRuby

[Fredrik Öhrström]

Rémi Forax skrev:
> Yes but the question is how a combine works ?
> If you re-read the mail from John, he says :
> "The idea is you get a subroutine to witness the full argument list and 
> make some computation,
> the result of which is injected back into the argument list before the 
> ultimate target is called."
>
> The question is what "injected back" means ?
>   
The javadoc for combineArguments is not completely clear. There is for
example confusion between the paragraph

"The combiner handle must have the same argument types as the target
handle, but must return MethodHandle instead of the ultimate return
type. The returned method handle, in turn, is required to have exactly
the given final method type. "

and the pseudo-code. I believe the pseudo-code to be the correct one,
which is as you use it in your example.

However. Injected can only mean one thing. The value calculated by the
combiner is used
as an argument to target. The difference between StackOverflow and
infinite loop
lies within the method handle that exactInvoker returns. With an
interpreter-only
solution it would be easy to implement an exact invoker methodhandle
that has tail
recursion, even though nothing else in your JVM has tail recursion. That
kind of
solution seems a bit too hardcoded for me.
> I know that hotspot already do this, in case of de-optimisation,
> so the question still hold:
> Is it hotspot specific or in JSR292 spec ?
>
> By the way, my code can be improved:
>
> MethodHandle target=MethodHandles.exactInvoker(
>    MethodType.make(void.class));
> MethodHandle combined=
>     MethodHandles.combineArguments(target, 0,
>         lookup().findVirtual(ThisClass, "combine",
>             MethodType.make(MethodHandle.class)
>         )
>     );
> ...
> MethodHandle combine() {
>   System.our.println("loop");
>   return combined;
> }
> ...
> combined.invoke();
>
> This avoid to re-create a combined MH at runtime.
>
> Rémi
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>