[10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

stanislav lukyanov stanislav.lukyanov at oracle.com
Thu Aug 24 06:49:52 UTC 2017

Thanks for the updates, Paul!

Some comments inlined.

On 23.08.2017 1:38, Paul Sandoz wrote:
>> First, implied `genericMethodType(N)` still fails with N > 255. It could safely be `genericMethodType(M)` though.
> Well spotted! I tweaked it to:
> * <li>Determine the general type {@code TN} of {@code N} arguments or
> *     {@code M} arguments, if smaller than {@code N}, as
> *     {@code TN=MethodType.genericMethodType(Math.min(N, M))}.</li>
Oh, right, `min(N, M)` should be better.
`M` could work as well (WMTE on arity mismatch would be thrown by 
`invokeExact` instead of `asType`),
but this way it's a bit easier to understand.
>> Second, it's unfortunate that varargs collection has to be re-implemented in the spec
>> for `invokeWithArguments` instead of reusing what `asVarargsCollector` has.
> I think this was always the case, but it has become more apparent with what is more clarification than arguably necessary to overcome the argument limitation. There is of course some notable differences between invokeWithArguments and invoke/invokeExact.
Well, before this patch `invokeWithArguments` didn't itself specify any 
varargs processing, just referred to `asType`.

There seems to be one more issue:
 > <li>Collect the trailing elements (there are {@code N-M+1} of them)
 > from the logical argument list into a single array of
 > type {@code A[]}, using {@code asType} conversions to
 > convert each trailing argument to type {@code A}. </li>
 > <li>If any of these conversions proves impossible, fail with a
 > {@code WrongMethodTypeException}. </li>
`asType(genericMethodType(N)).invokeExact(...)` would throw CCE, not WMTE.
At link-time it would only see `Object` types which never fail to be 
collected to varargs, so no WMTE.
At run-time, the casts may fail producing ClassCastException.

I still think that instead of debugging this spec and making sure that 
it behaves similarly to `asType`
it would be better to keep delegating to the implied `asType` and allow 
it not to throw IAE for too many parameters.


More information about the core-libs-dev mailing list