GROOVY-12185: Move classic call-site caching into optional groovy-callsite module

[daniellansun]

https://issues.apache.org/jira/browse/GROOVY-12185

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.50.

Benchmark suite	Current: 4eccbf1	Previous: 3240fcf	Ratio
org.apache.groovy.bench.NonCapturingLambdaBench.capturingLambdaApply	58199.82657236301 ops/ms	38578.09588384062 ops/ms	1.51
org.apache.groovy.bench.AryBench.java ( {"n":"1000"} )	0.11818123416486022 ms/op	0.05959038168742412 ms/op	1.98

This comment was automatically generated by workflow using github-action-benchmark.

[github-actions]

JMH summary — classic (commit 5e4e88a)

Speedup vs trailing 90-day baseline on gh-pages. Higher = faster.
1.00 = in line with history. Per-benchmark ratio, geomean within group.
Time-per-op units inverted so direction is consistent. The calibrated
column divides out this runner's speed vs the baseline hardware, as
measured by Groovy-independent pure-Java ruler benchmarks.

Group	Speedup	Calibrated	n
bench	0.982 ×	0.992 ×	84
core	1.223 ×	1.090 ×	77
grails	0.941 ×	0.833 ×	80

⚠️ Runner speed differs ≥15% from the historical baseline hardware for: core-hz. Raw speedups are not meaningful for those parts — use the calibrated column.

_{Runner calibration (this run vs baseline hardware): bench 0.99× (26 rulers) · core-ag 1.00× (3 rulers) · core-hz 1.28× (3 rulers) · grails-ad 1.11× (3 rulers) · grails-ez 1.15× (3 rulers)}

_{Baseline: dev/bench/jmh/<part>/classic/data.js on gh-pages, trailing 90 days. Daily dashboard · Per-suite raw data}

[github-actions]

JMH summary — indy (commit 5e4e88a)

Speedup vs trailing 90-day baseline on gh-pages. Higher = faster.
1.00 = in line with history. Per-benchmark ratio, geomean within group.
Time-per-op units inverted so direction is consistent. The calibrated
column divides out this runner's speed vs the baseline hardware, as
measured by Groovy-independent pure-Java ruler benchmarks.

Group	Speedup	Calibrated	n
bench	no overlap with baseline	—	0
core	4.034 ×	3.360 ×	77
grails	2.585 ×	2.160 ×	80

⚠️ Runner speed differs ≥15% from the historical baseline hardware for: core-ag, grails-ad. Raw speedups are not meaningful for those parts — use the calibrated column.

_{Runner calibration (this run vs baseline hardware): core-ag 1.45× (3 rulers) · core-hz 0.97× (3 rulers) · grails-ad 1.44× (3 rulers) · grails-ez 1.03× (3 rulers)}

_{Baseline: dev/bench/jmh/<part>/indy/data.js on gh-pages, trailing 90 days. Daily dashboard · Per-suite raw data}

[blackdrag]

I am a bit worried about the metaclass changes since it kind of means changing public API. And I was wondering if can somehow provide an alternative. Maybe we don´t need that as most people probably do not use those callsite methods. But if we do need to compatibility I was wondering if we could solve it with a parallel meta class system. What I mean is that if callsites are active we use the callsite variants and otherwise we use the normal meta class. Maybe the callsite meta classes could just wrap the normal metaclass and delegate calls... the classic way of trying to solve a problem by adding a level of indirection. But the basic question is really: Do we need to keep those methods on the meta classes? @paulk-asert what do you think? If we say we do not need it, then I would agree to the change.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 67.15328% with 45 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.7625%. Comparing base (3240fcf) to head (4eccbf1).

Files with missing lines	Patch %	Lines
...us/groovy/runtime/callsite/MetaClassCallSites.java	44.6154%	22 Missing and 14 partials ⚠️
...groovy/runtime/callsite/CachedMethodCallSites.java	83.7838%	5 Missing and 1 partial ⚠️
src/main/java/groovy/lang/MetaClassImpl.java	50.0000%	2 Missing ⚠️
...codehaus/groovy/classgen/asm/WriterController.java	88.8889%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##               master      #2730        +/-   ##
==================================================
+ Coverage     69.2732%   69.7625%   +0.4893%     
- Complexity      34769      34815        +46     
==================================================
  Files            1542       1543         +1     
  Lines          130456     129670       -786     
  Branches        23786      23655       -131     
==================================================
+ Hits            90371      90461        +90     
+ Misses          31962      31076       -886     
- Partials         8123       8133        +10     

Files with missing lines	Coverage Δ
src/main/java/groovy/lang/ExpandoMetaClass.java	79.0787% <100.0000%> (+1.9411%)	⬆️
...g/codehaus/groovy/classgen/asm/CallSiteWriter.java	86.5385% <100.0000%> (+0.9615%)	⬆️
...codehaus/groovy/control/CompilerConfiguration.java	72.6351% <ø> (ø)
...va/org/codehaus/groovy/reflection/CachedClass.java	71.0084% <ø> (-0.3609%)	⬇️
...a/org/codehaus/groovy/reflection/CachedMethod.java	80.3738% <ø> (+16.2713%)	⬆️
...roovy/reflection/ClassLoaderForClassArtifacts.java	75.0000% <100.0000%> (ø)
...dehaus/groovy/runtime/dgmimpl/NumberNumberDiv.java	100.0000% <ø> (+96.4602%)	⬆️
...groovy/runtime/dgmimpl/NumberNumberMetaMethod.java	87.5000% <ø> (+73.2143%)	⬆️
...haus/groovy/runtime/dgmimpl/NumberNumberMinus.java	100.0000% <ø> (+97.0803%)	⬆️
...s/groovy/runtime/dgmimpl/NumberNumberMultiply.java	100.0000% <ø> (+97.0803%)	⬆️
... and 57 more

... and 14 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[paulk-asert]

I am keen for this work to be eventually done. I need to think more about whether we are ready for this in Groovy 6 or whether this might be better in Groovy 7. I will need a few more days to absorb it.

[sonarqubecloud]

Quality Gate failed

Failed conditions
44.8% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: 4eccbf1
▶️ Tests: 105419 executed
⚪️ Checks: 31/31 completed

---

Learn more about TestLens at testlens.app.