daniellansun commented on code in PR #2790:
URL: https://github.com/apache/groovy/pull/2790#discussion_r3790871927
##########
src/main/java/groovy/lang/Closure.java:
##########
@@ -1593,7 +1650,26 @@ static CallOverride lookup(Class<?> type) {
}
any = true;
}
- return any ? new CallOverride(byArity, guards, callForm) : NONE;
+ if (!any) {
+ return NONE;
+ }
+ MethodHandle[] handles = new MethodHandle[ARITY_LIMIT];
+ for (int arity = 0; arity < ARITY_LIMIT; arity += 1) {
+ if (byArity[arity] != null) {
+ handles[arity] = unreflect(byArity[arity]);
+ }
+ }
Review Comment:
Agreed, and that is now in place.
`ARITY_LIMIT` is only the specialised-`invokeExact` cutoff (`0..4`).
`doCall` methods with `arity >= 5` are no longer skipped. Each unambiguous,
non-array target is stored in a small side table (`SpreadSlot[]`), keyed by
exact parameter count, as a lookup-time `asSpreader` of type `(Object,
Object[])Object`.
We kept that table off the `handles[0..4]` array on purpose:
- mixing the two handle shapes in one array would `WrongMethodTypeException`
if the wrong `invokeExact` form were used;
- a single catch-all `(Object, Object[])` slot cannot represent both a 5-arg
and a 6-arg `doCall` (`asSpreader` is arity-specific);
- array-typed / varargs `doCall` still belongs to the MOP (`hasArray` skip),
as before.
Selection, GROOVY-12164 guards, ambiguity, `MethodClosure` /
`CurriedClosure` → `NONE`, and the `mopUnperturbed` gate are the same rules as
for `0..4`. High-arity is always a `doCall` body, so it does not use the
GROOVY-11911 re-entry latch.
The `0..4` branch in `call(Object...)` (`arity < ARITY_LIMIT`) is unchanged,
so the measured GDK path is not on this table.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
