Daniel Sun created GROOVY-12263:
-----------------------------------

             Summary: Invoke cached Closure doCall targets via MethodHandle
                 Key: GROOVY-12263
                 URL: https://issues.apache.org/jira/browse/GROOVY-12263
             Project: Groovy
          Issue Type: Improvement
            Reporter: Daniel Sun


The {{Closure.call(Object...)}} fast path (GROOVY-11911, GROOVY-12164, 
GROOVY-12165) already caches a per-arity {{doCall}} / {{call}} {{Method}} and 
invokes it with {{Method.invoke}}. That still puts a reflective invoke — access 
check, argument boxing, {{InvocationTargetException}} wrap — on every GDK 
{{each}} / {{collect}} / {{findAll}} / {{inject}} callback from Java.

h2. Proposal

At cache-build time, {{MethodHandles.unreflect}} the cached {{Method}} and 
adapt it to {{genericMethodType(arity+1)}}. {{call(Object...)}} then prefers 
{{invokeExact}} on that handle (specialized for arities 0–4). {{Method.invoke}} 
remains only when the method cannot be adapted, so the GROOVY-11911 {{call()}} 
/ {{call(Object)}} carve-out still works if unreflect fails.

Exception contracts stay as they were on the reflective path: a body-thrown 
throwable surfaces unwrapped. The handle path must not treat a body-thrown 
{{InvocationTargetException}} or {{IllegalAccessException}} as a reflection 
wrapper.

Guards, {{CallOverride.NONE}} for {{MethodClosure}} / {{CurriedClosure}}, and 
the metaclass fallback for coercion (GROOVY-12164) are unchanged.

h2. Why this path

Java callers such as {{DefaultGroovyMethods}} resolve {{closure.call(item)}} to 
{{Closure.call(Object)}}, which wraps into {{call(Object...)}}. Groovy 
{{invokedynamic}} sites typically bind straight to {{doCall}} after warmup and 
never enter this method — they are out of scope.

h2. Verification

Same-host JMH, 4 forks, 99.9% CI, parent {{9bb195dee5}} vs {{1c3820bff7}}, JDK 
25. Host-calibration geomean 0.998x.

|| bench || speedup ||
| {{eachWithClosure}} | 1.171x |
| {{collectWithClosure}} | 1.163x |
| {{findAllWithClosure}} | 1.128x |
| {{injectWithClosure}} | 1.212x |
| GDK geomean | 1.168x (~5 ns/callback) |
| Groovy-indy {{doCall}} sites | 0.990x (flat) |
| {{MethodClosure}} ({{list.&size}}) | 0.994x (flat) |

All four GDK 99.9% CIs are disjoint. Full write-up: 
{{docs/closure-call-methodhandle-perf-report.md}}.

h2. Related

GROOVY-11911 introduced the reflective cache. GROOVY-12164 / GROOVY-12165 
extended it with typed and multi-arity guards. This change keeps that selection 
and only replaces the invoke.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to