Trying to work newer indy into JRuby

[John Rose]

On May 20, 2009, at 6:15 AM, Rémi Forax wrote:

>> The combineArguments combinator is both polymorphic and pretty nearly
>> universal (without boxing).  I hope to implement it mostly "in the
>> metal", under the name "flyby adapter".  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.  If the injected value is
>> itself a method handle, and the ultimate target is MH.invoke, then we
>> have the makings of a threaded interpreter, all inside a method  
>> handle
>> nest.  Therefore, inlinable in the LLVM sense.
>>
>
> Wow ...
> So this code will create a forever loop and not a StackOverflowError ?
>
> MethodHandle target=MethodHandles.exactInvoker(
>   MethodType.make(void.class));
> MethodHandle combiner=lookup().findVirtual(ThisClass, "combine",
>   MethodType.make(MethodHandle.class));
> ...
> MethodHandle combine() {
>  System.our.println("loop");
>  return MethodHandles.combineArguments(target, 0, combiner);
> }
> ...
> combiner.invoke();
>
>
> Is it the behavior of the hotspot implementation or the one required
> by the spec ?

That gets close to putting the "Y" in flyby.  :-)  http://en.wikipedia.org/wiki/Fixed_point_combinator

Whether this should be guaranteed to run forever without a SOE is an  
issue the EG needs to look at (it's on the list).

Certainly if we integrate tail-calls, then it will be upgraded.  But  
there is probably some value in making the guarantee even now.

-- John