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
