Trying to work newer indy into JRuby
Rémi Forax
forax at univ-mlv.fr
Fri May 22 03:46:24 PDT 2009
Fredrik Öhrström a écrit :
> Rémi Forax skrev:
>
>> 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();
>>
>>
> I assume that you mean combine().invoke() ? :-)
> When I read the spec, the method handle invocations is specified to
> behave "as if" an
> invokestatic/invokespecial/invokevirtual call was made. This means that,
> most
> likely the JVM will throw a StackOverflowError. Unless the JVM has
> implemented
> tail recursion. I.e. it is not specified.
>
> //Fredrik
>
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 ?
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
More information about the mlvm-dev
mailing list