John Rose a écrit :
> On May 19, 2009, at 1:00 AM, Rémi Forax wrote:
>
>
>> The purpose of primitive adapters is to hep the language developer
>> to fight
>> the inherent complexity of dealing with polymorphic signature.
>>
>
> Yes, that's the key point.
>
> As Fredrik says, you can hide the polymorphism by going to a
> reflective (fully boxed) calling sequence. But, we've had 10 years to
> learn to optimize that reliably, and we don't. Some JVMs optimize
> boxing sometimes, but not all do, and it is historically a hard
> problem. A goal of the present design is for the new facilities to
> support the full range of JVM calling sequences, including native
> (unboxed) primitives.
>
> The set of combinators in MHs is not minimal, but it is only a step or
> two away (I hope) from being tasteful.
>
> If a JVM has excellent boxing analysis, then it can implement these
> combinators very easily on top of Lisp-y rest-args. But we can't
> presume that for all JVMs.
>
> 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 ?
> I expect to implement guardWithTest on top of combineArguments.
>
> -- John
>
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
