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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
