You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by James Fredley <ja...@apache.org> on 2026/01/28 23:16:13 UTC
Draft PR: GROOVY-10307: Improve invokedynamic performance with optimized caching
I have submitted a draft PR which significantly improves invokedynamic
performance in Grails 7 with Groovy 4, while passing the tests in the
Groovy build.
Optimizing Indy performance is well outside my expertise, but I'm
hopeful this PR will help pave the way for better optimizations for
Groovy-based applications like Grails, where frequent metaclass
modifications currently invalidate all call sites leading to slower
execution.
https://github.com/apache/groovy/pull/2374
James Fredley
Re: Draft PR: GROOVY-10307: Improve invokedynamic performance with optimized caching
Posted by Jochen Theodorou <bl...@gmx.org>.
I find the idea very interesting.
I think what happens is that if you invalidate with the switchpoint,
then you have first the call to the switchpoint, then you have the call
to from cache, which will replace the handle for the callsite. In this
new mechanism we skip the first half of the call and directly replace
with from cache to then again replace with whatever from cache chose.
The big difference is that the switchpoint is a lazy mechanism, while
this new one is an pro-active mechanism. So... if we have a system with
a lot of stale callsites that are never going to be visited, well, we
pay going through that array and that's it. I think that is a negligible
cost. So I am all good with this so far!
bye Jochen
On 30.01.26 06:49, James Fredley wrote:
> This PR has been updated and significantly simplified while producing
> nearly identical results in the Grails test application.
>
> James Fredley
>
> On 1/28/2026 6:16 PM, James Fredley wrote:
>> I have submitted a draft PR which significantly improves invokedynamic
>> performance in Grails 7 with Groovy 4, while passing the tests in the
>> Groovy build.
>>
>> Optimizing Indy performance is well outside my expertise, but I'm
>> hopeful this PR will help pave the way for better optimizations for
>> Groovy-based applications like Grails, where frequent metaclass
>> modifications currently invalidate all call sites leading to slower
>> execution.
>>
>> https://github.com/apache/groovy/pull/2374
>>
>> James Fredley
>
Re: Draft PR: GROOVY-10307: Improve invokedynamic performance with optimized caching
Posted by James Fredley <ja...@apache.org>.
This PR has been updated and significantly simplified while producing
nearly identical results in the Grails test application.
James Fredley
On 1/28/2026 6:16 PM, James Fredley wrote:
> I have submitted a draft PR which significantly improves invokedynamic
> performance in Grails 7 with Groovy 4, while passing the tests in the
> Groovy build.
>
> Optimizing Indy performance is well outside my expertise, but I'm
> hopeful this PR will help pave the way for better optimizations for
> Groovy-based applications like Grails, where frequent metaclass
> modifications currently invalidate all call sites leading to slower
> execution.
>
> https://github.com/apache/groovy/pull/2374
>
> James Fredley
Re: Draft PR: GROOVY-10307: Improve invokedynamic performance with optimized caching
Posted by James Fredley <ja...@apache.org>.
This PR has been updated and significantly simplified while producing
nearly identical results in the Grails test application.
James Fredley
On 1/28/2026 6:16 PM, James Fredley wrote:
> I have submitted a draft PR which significantly improves invokedynamic
> performance in Grails 7 with Groovy 4, while passing the tests in the
> Groovy build.
>
> Optimizing Indy performance is well outside my expertise, but I'm
> hopeful this PR will help pave the way for better optimizations for
> Groovy-based applications like Grails, where frequent metaclass
> modifications currently invalidate all call sites leading to slower
> execution.
>
> https://github.com/apache/groovy/pull/2374
>
> James Fredley
Re: Draft PR: GROOVY-10307: Improve invokedynamic performance with optimized caching
Posted by Remi Forax <fo...@univ-mlv.fr>.
Hello James,
LLMs really suck at concurrency, it's their kryptonite.
By example, in the first two lines
https://github.com/apache/groovy/pull/2374/changes#diff-9509de7dd59037252adc9ad813535d0a5ce8c0b4960eaba0efae6ccafbbc43f1R43
Having two volatiles means that a thread can see on field being updated while the other is not yet updated,
and storing the class as a String will not work once ClassLoaders are involved (you can more than one class with the same name).
regards,
Rémi
----- Original Message -----
> From: "James Fredley" <ja...@apache.org>
> To: "dev" <de...@groovy.apache.org>, dev@grails.apache.org
> Sent: Thursday, January 29, 2026 12:16:13 AM
> Subject: Draft PR: GROOVY-10307: Improve invokedynamic performance with optimized caching
> I have submitted a draft PR which significantly improves invokedynamic
> performance in Grails 7 with Groovy 4, while passing the tests in the
> Groovy build.
>
> Optimizing Indy performance is well outside my expertise, but I'm
> hopeful this PR will help pave the way for better optimizations for
> Groovy-based applications like Grails, where frequent metaclass
> modifications currently invalidate all call sites leading to slower
> execution.
>
> https://github.com/apache/groovy/pull/2374
>
> James Fredley