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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
