Trying to work newer indy into JRuby

[Rémi Forax]

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