Re: Draft PR: GROOVY-10307: Improve invokedynamic performance with optimized caching

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" <[email protected]>
> To: "dev" <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]>, dev-FvxHgLy0BgRd/SJB6HiN2Ni2O/[email protected]
> 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