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