On Jan 28, 2011, at 7:09 AM, Jim Laskey wrote:
> Unfortunate was an incomplete thought.
>
> What I was thinking was, that there was likely no trivial way to treat
> exactInvoker(target.type()).bindTo(target) as identity (in bindTo) when
> !target.isVarargsCollector(). Likely moot as MH optimization gets better.
Good thought. The bindTo is likely to be a virtual function inside an
implementation MH hierarchy. (It isn't now, but that's just the initial
implementation.) If there is an ExactInvokeMH.bindTo, it can almost be a
simple "return target". But instead it must be "return
target.asNonVarargsCollector()", where asNonVarargsCollector is an internal
function. All of this stuff is optimizable.
What bothers me a little about bindTo erasing varargs it disturbs the
left-curry operation in languages with restarg/apply:
public static MethodHandle leftCurry(MethodHandle x, Object y) {
MethodHandle xy = x.bindTo(y);
// preserve varargs property from x to xy:
if (x.isVarargsCollector()) {
MethodType xyt = xy.type().parameterCount();
int xytc = xyt.parameterCount();
if (xytc > 0)
xy = xy.asVarargsCollector(xyt.parameterType(xytc-1));
}
return xy;
}
Although it would be reasonable for bindTo to manage this bit, Remi has pointed
out that, in that case, all the other method handle combinators might have to
be reexamined for the same condition. Nobody can say (at present) where the
changes would stop.
Similar proposals can be made with dropArguments, insertArguments,
permuteArguments, filterArguments, foldArguments, filterReturnType,
convertArguments, etc. As long as the initial target MH is varargs, and the
transform preserves the trailing array argument, it would seem reasonable (in
some use cases) to make the result be varargs also. But that's only in some
use cases, not all.
Internally in my code, I use this little transform. That's probably all the
user needs, and it can be user-defined:
/** Return a version of MH which matches matchMH w.r.t. isVarargsCollector. */
static MethodHandle fixVarargs(MethodHandle mh, MethodHandle matchMH);
-- John
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
