Spread problem with > 10 arguments

[Fredrik Öhrström]

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.

> 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.

Co/contra variance will follow.

The effects of generic invocation only happens when the
current spec would have thrown an InvocationTargetException.
Therefore  it >must< be compatible for every application that
does not rely on an exception to be thrown.

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.

//Fredrik