RFR (XS): 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs
John Rose
john.r.rose at oracle.com
Tue Jul 2 14:04:51 PDT 2013
Good fix, good test.
Suggestions for the test:
Change e.printStackTrace() to throw new AssertionError(e), to get earlier detection of config error.
Suggest using a more specific type than Exception, maybe even a specific instance (like firstArg), to rule out interference from accidental errors. Then detect the caught exception in the handler, before returning the desired value.
Suggest defining MAX_ARITY (MAX_MH_ARITY?) more categorically as 254, with a comment. Then have the loop go up to MAX_ARITY-1 with a comment, or put a break at the bottom of the loop body:
if (handlerWithArgs.type().parameterCount() == MAX_MH_ARITY) break; // no more cases possible
As we have seen, arity limits are hard to reason about!
(Instead of dropArgs you could use something like MethodType.methodType(Object.class, Exception.class, ptypes.toArray()).)
— John
On Jul 2, 2013, at 1:33 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> http://cr.openjdk.java.net/~twisti/8019184/webrev/
>
> 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs
> Reviewed-by:
>
> The bug seems to be in MethodHandlesImpl.makeGuardWithCatch using ValueConversions.varargsArray:
>
> return makeCollectArguments(ginvoker, ValueConversions.varargsArray(nargs), 0, false);
>
> ValueConversions.varargsArray returns a MethodHandle which's type is:
>
> MethodHandle(Object,Object,Object,Object,Object,Object,Object,Object,Object)Object[]
>
> It doesn't preserve the trailing Object[].
>
> The fix is to call makePairwiseConvert on the result of makeCollectArguments.
>
> src/share/classes/java/lang/invoke/MethodHandleImpl.java
> test/java/lang/invoke/TestCatchExceptionWithVarargs.java
>
More information about the hotspot-dev
mailing list