Spread problem with > 10 arguments

[Rémi Forax]

Fredrik Öhrström a écrit :
> Rémi Forax skrev:
>   
>> The problem is that for some adapters (by example collectArguments)
>> the bytecode size grow following a quadratic curve in relation to
>> the number of arguments.
>> This means that if you have more than let say 10 arguments the size of
>> bytecode for such adapters disable inlining which is the mother of all 
>> optimisations.
>>   
>>     
> I am not sure I understand what you mean. Please, have a look at my
> example of CollectArguments implementation here:
> http://blogs.oracle.com/ohrstrom/2009/05/pulling_a_machine_code_rabbit.html#Collect
>
> The size of each adapt method grows linearly with the number of arguments.
> This will not prevent inlining.
>
>   

Your implementation doesn't follow the spec :
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/java/dyn/MethodHandles.html#collectArguments(java.dyn.MethodHandle,%20java.dyn.MethodType)

Only trailing arguments for a given position are collected :
http://code.google.com/p/jvm-language-runtime/source/browse/trunk/invokedynamic-backport/src/jsr292/java/dyn/MHCollecter.java

So it grows quadratically or you have to create on class by collect 
position.


>> A minor correction. The backport doesn't generate a call chain
>> but inline the method handles chain into a single block of code
>> containing only end method calls.
>>   
>>     
> This is what I meant. :-) The only reasonable way to
> optimize a chain of method handles is to inline. This
> is true both for your backport code and the JRockit
> example I gave.
>   
>> Let me try to summarize :
>> - current spec require a == check before calling a sequence
>>   of adapters  that ends  with a call  to a  Java  method.
>>   
>>     
> Yes, a single comparison is necessary, for each method
> handle invoke in the adapter sequence,  that the
> call site method type is identical to the methodhandle
> target method type. If ok, call the destination otherwise
> throw an Exception.
>   
>> - generic invocation (variant invocation) requires
>>   to check the number of argument at call site and
>>   to ensure that only a valid method
>>  (contravariant of parameter types/covariant of return type)
>>  by inserting cast where needed.
>>   
>>     
> The simple change to JSR292 is that every argument handed
> to a method handle invoke, will be cast to the target argument
> type. Potentially boxing/unboxing. If the number of arguments
> differ, give up.
>   

It's not a simple change because  between the call site  and the target
method you have a bunch of adapters.
generic invocation means two different paths between the call site and
the target method because when the target method is reached
the former will just call the target method and the later will have to
do some checkcasts before calling the method.

Maintaining these two paths is practicable but not simple.

> Co/contra variance will follow.
>
> The effects of generic invocation only happens when the
> current spec would have thrown an InvocationTargetException.
>   
you mean WrongMethodTypeException :)
> Therefore  it >must< be compatible for every application that
> does not rely on an exception to be thrown.
>   

I agree, sorry to use 'compatible', you're right it's compatible.

> You can check if a cast is really needed or not, and you can go directly
> to the target method if the method types match exactly, and you
> can inline, but these actions are merely optimizations that might or
> might not be performed by the JVM. Going through Object references
> is one such optimization for JVMs that want to compile virtual method
> handle calls that cannot be inlined. But to the outside, it simply
> looks like the arguments are cast to the target argument types.
>   

I have a tendency to agree with you, but you have to agree that this is not
a simple change but another way to see the invocation of method handles.

As the backport implementor, it will not change my world,
the end of the adapter chain relies on reflection (at least currently)
and thus already do these checkcasts and the optimizer only optimized 
call sites
that always use the same method handle and therefore
knows the exact method types.

John, Christian, what do you think about that ?

> //Fredrik
>   

Rémi