Hi Gianluca,
1. You and I are both (rightfully) worried about Groovy INDY
performance degradation (Even though in our organization we were
able to get back to previous performance levels by adapting a very
specific, very hard to find part of our code, as well as switching
all our core project modules to @CompileStatic).
2. However I do not think that querying ("asking") any Large Language
Model and posting the resulting text ouput verbatim here does help,
since these high dimensional databases with stochastic output
generation do not understand anything, but are just execellent at
producing believable human-like output from the vast amounts of data
stored inside their system.
3. Anything an LLM would produce as a reply, would have to be based on
something it has seen on the internet, so it became part of the data
stored in its neural network.
4. While this works to some extent on code that has been written a
million times already, or problems that are widely discussed, it
does not for a language like Groovy, on which very little currently
applicable data exists.
5. Therefore here you run into the problem, that some factual things
will be conflated with a lot of outdated information, information
that applies to other computer languages, etc.
1. You can in my opinion see this in Jochen's replies to the LLM
bullet list.
6. It would therefore imho make more sense to do a Google search on the
topic, restricted to data e.g. 1 to 3 years back, and see if someone
who is not on this mailing list has actually written about this
problem somewhere (unlikely as this is)...
1. (Despite the understandable protesting & massive propaganda
efforts by companies that have invested hundreds of billions of
dollars into LLMs & their infrastructure, the term "AI slop"
exists for a reason, and it does not only apply to images and
videos, but also to (especially the truthfulness of) text,
however deceptively well constructed LLM generated texts are...)
Cheers,
mg
Am 16.01.2026 um 10:22 schrieb Gianluca Sartori:
Hi Jonny,
I've used chatGPT just to raise questions more than give a solution. I
am unfortunately not in the position to work on it, I don't have
experience on language development (I am sure the Assembly compiler I
developed when I was in High School does not qualify).
At the moment the role I can play is to make sure we don't
forget about performance, because what's happening is that we are
degrading instead of improving.
I am aware that this is not an easy task and I don't want to sound
rude It's just that I'm writing a bit in a hurry.
Gianluca Sartori
--
https://dueuno.com
On Thu, 15 Jan 2026 at 22:20, Jonny <[email protected]> wrote:
Before we go back and forth too much with Jochen fact-checking GPT
output, may I recommend Gianluca try giving the agent a laboratory
to work with? See
https://brianlovin.com/writing/give-your-agent-a-laboratory (first
example prompt in that doc is even about performance, though
there'd obviously be tweaks since you're dealing with a language,
not a backend).
Regardless of the LLM, making the agent build the kinds of
performance tests and investigate their output is the only way
you're likely to get meaningful output. Otherwise, you are indeed
in the predictive text spin cycle. It does require more time, but
it's also the only way you're likely to get coherent, usable output.
Best,
Jonny
On Wed, Jan 14, 2026 at 2:57 PM Jochen Theodorou
<[email protected]> wrote:
On 14.01.26 15:32, Gianluca Sartori wrote:
[...]
> *
>
> *Groovy 5* moved most dynamic calls to |CallSite|
caching through
> |indy|.
correct, though it was before in the equivalent code for the
bytecode
generation
> *
>
> *Groovy 3* often inlined certain calls more
aggressively, sometimes
> relying on slower reflection but faster in
microbenchmarks due to
> simpler call chains.
which type of calls though? It was faster in some
micro-benchmarks
because we had a full primitive path parallel to the
non-primitive path
maybe. This worked only with unchanged meta classes, so not
sure Grails
had much of it. Which also shows a big difference, a
micro-benchmark is
not an app and you have to know what you actually test
> *
>
> *Result:* |invokedynamic| can introduce overhead for
short-lived
> calls or highly polymorphic code because of frequent
call site
> relinking.
that would have impacted performance on non-indy as well
> Key reasons for slowness:
>
> 1.
>
> *Polymorphic call sites:* If your code calls many
different methods
> dynamically at the same call site, the |invokedynamic|
bootstrap has
> to relink repeatedly.
>
> 2.
>
> *CallSite cache invalidation:* Changes to the meta-class
or dynamic
> method addition can invalidate call sites.
as I said, that counts for both variants.
> 3.
>
> *Boxing/unboxing overhead:* Primitive-heavy code may
suffer due to
> dynamic dispatch.
well, that is not supposed to be an issue in indy. It was in
the old
callsite code in Groovy 3
> 4.
>
> *JIT warmup issues:* The JVM may take longer to optimize
> |indy|-based dispatch.
that is actually a factor. But a proper micro-benchmark will
not measure
warmup times, right?
>
------------------------------------------------------------------------
>
>
> *2. Optimization Strategies for a Next Groovy Version*
>
>
> *A. Improve CallSite Caching*
>
> *
>
> Implement *multi-level caching* for polymorphic call sites.
>
> *
>
> Use *polymorphic inline caches (PICs)* like modern
JavaScript
> engines (V8) to avoid relinking.
basically agree
> *
>
> Avoid global call site invalidations when meta-classes
are updated —
> make call site invalidation more local.
how?
> *B. Reduce Relinking*
>
> *
>
> Track method signatures more strictly. Many
|invokedynamic| relinks
> happen because Groovy tries to handle any dynamic call,
even when
> the call target is stable.
True. If you call foo(Object) with a String and then with an
Integer it
will cause relinking, even though it is not required
> *
>
> Consider *specialized bootstrap methods* for common call
patterns:
>
> o
>
> e.g., frequent calls to |String| methods,
|List|/|Map| operations.
on what are we actually saving here?
> *C. Optimize Primitive Handling*
>
> *
>
> Introduce *primitive specialization* for arithmetic and
collection
> operations.
>
> *
>
> Reduce boxing/unboxing by generating specialized call
site versions
> for primitives (like what Kotlin/JVM or Scala do with
inline functions).
we have
> *D. Optional Static Call Optimization*
>
> *
>
> Provide *hybrid static/dynamic dispatch*:
>
> o
>
> Use static compilation (|@CompileStatic|) when possible.
on the compiler side directly? Well... when is it possible?
> o
>
> Use a *profiling-guided JIT* to replace call sites
with direct
> method handles if a single target dominates.
well.. and how does the invalidation work if the target is
suddenly
incorrect?
> *E. Bytecode Generation Improvements*
>
> *
>
> Investigate how Groovy 5 generates |invokedynamic| bytecode:
>
> o
>
> Avoid unnecessary |Object| casts.
>
> o
>
> Combine multiple small dynamic calls into a single
bootstrap
> call to reduce overhead.
Have that afaik
> *
>
> Possibly generate *direct method handles* for commonly
called Groovy
> methods (|size()|, |get()|, etc.).
see above
> *F. JIT-Friendly Bootstrap*
>
> *
>
> Groovy could provide *simpler bootstrap methods* to
allow JVM JIT
> inlining:
>
> o
>
> Reduce bootstrap method complexity to help HotSpot
optimize the
> call site faster.
not bootstrap complexity, but the resulting handle should have
as little
complexity in there as possible
>
------------------------------------------------------------------------
>
>
> *3. Micro-Optimizations for Library Authors*
>
> If you are writing a library or code in Groovy that must be
fast:
>
> 1.
>
> *Prefer static types* whenever possible — even without
> |@CompileStatic|, type hints help.
which leads to more casting... so no.
> 2.
>
> *Use |@CompileStatic|* selectively for hot loops.
possibly
> 3.
>
> *Avoid meta-class changes* at runtime in
performance-critical code.
well, they is currently no way to protect an area against meta
class changes
> 4.
>
> *Cache dynamic lookups manually* for very hot methods.
not understood
> 5.
>
> *Use primitive arrays* instead of boxed lists when
dealing with numbers.
possibly.
> 6.
>
> *Minimize polymorphism at call sites* — repeated calls
to the same
> method is much faster than alternating between multiple
methods.
correct
>
------------------------------------------------------------------------
>
>
> *4. Experimental Ideas for Groovy 6+*
>
> *
>
> *CallSite specialization per type* (like Truffle/Graal
dynamic
> languages).
I would like to make a MethodHandle part of the MetaMethod. I
guess that
goes in that direction.
> *
>
> *Inline small closures automatically* at compile-time.
It is not only the code of the Closure, it is also the code
of the
Closure handling method. in i=0; n.times{i++} it does not
actually help
to "inline" i++, because we would have to inline it to the
times method.
Instead we have to inline times as well of course with the
danger, that
if we change times, it will not be reflected without recompilation
> *
>
> *Profile-guided call site replacement*: replace
|invokedynamic|
> calls with direct |MethodHandle| or static calls at
runtime if
> profiling shows a stable target.
I cannot replace it with static calls
> *
>
> *Better JIT feedback*: provide hints to HotSpot that
certain call
> sites are monomorphic or polymorphic.
How?
bye Jochen
