MethodHandle.bindTo() only for reference types?

[Rémi Forax]

On 07/24/2012 09:02 PM, John Rose wrote:
> On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote:
>
>> I don't think technically there'd be a difficulty in having it
>> work on primitives, it's just that it ain't the intent; you still use
>> insertArguments() for uses that are not semantically "bind"s.
>
> MethodHandle.bind is a less-general primitive. The general API is 
> insertArguments.
>
> Good 292 support for primitives requires a signature-polymorphic API.
>
> Therefore, we have been considering adding something like this, to 
> fill functionality not covered by bind and insertArguments:
>
> class MethodHandle {
> /** Binds the given argument(s) to the method handle, but does not 
> invoke it.
> * Arguments are not boxed, but rather passed in a 
> signature-polymorphic call.
> * Requires an exact match to the corresponding leading parameter types.
> * Returns a method handle which accepts any remaining arguments,
> * and invokes the original on the combined argument lists.
> * Equivalent to insertArguments(this, 0, args), but may be more efficient.
> * Equivalent to this.bind(args[0]), but may be more efficient.
> */
> public final native MethodHandle invokePartial(Object… args) throws 
> Throwable;
> }
>
> If we do, we will first experiment internally with it (as a non-public 
> API).

invokePartial is in fact, invokedynamic + insertArguments + 
insertArguments (to insert 0) + asType(asVarargCollector) + escape 
analysis (to remove the array allocation and boxing).
I would prefer a way to gently ask the compiler to substitute a 
classical Java call to an invokedynamic one.

The question is: are VMs able to do the escape analysis here or not.
BTW, invokePartial is important because it is the primitive needed when 
you want to create a lambda that capture some values from the scope
so even Java will use it.

>
> — John

Rémi