Re: version planning

Hi Paul,

I am still trying to find the key to making indy performing better on=20
cold calls (and in general). Something that seems to be a real uphill=20
battle.

Maybe a small extract of things I concluded so far...

Reflection:
* Reflection in newer Java uses MethodHandles and is very fast
* Reflection will get us no where in the problem area of JPMS or=20
@CallerSensitive. That said, this is for a central invoke style=20
invocation like MetaClass.invoke or InvokerHelper.invoke. There might be=
=20
ways around.
* Reflection is fast for the cold path because they use only very few=20
LambdaForms in the end

MethodHandles:
* have a huge one-time-creation cost per lambda form, which is cached.
* adapters caused by insertArguments, folding, asType and all that=20
change the Lambdaform, resulting in huge one time cost.
* A simple invocation of a MethodHandle with an previously unused lambda=
=20
form results in code that performs about 10-15 times slower than doing=20
the same  via reflection on the cold path
* important: cold path is not hot path, it has to be looked at=20
independently and is for the first few invocations
* @CallerSensitive and JPMS can be made working properly for this
* Reflective Methods can be unreflected to get a MethodHandle, but these=
=20
are not the high performing handles Reflection uses inside.

HiddenClasses nest mates:
* could be used to replace our current bytecode generation for callsites
* they are part of the same classloader and module, making the old=20
callsite mechanism more interesting for the JPMS case again.
* This will not gain performance, but may make things more "correct" and=
=20
usable for JPMS
* Still @CallerSensitive may not work properly for this. The same as=20
now. But for getting the caller class loader or module, this would work=20
better than now.
* bytecode generation (hidden class or not) is even more expensive for=20
the cold path

The whole thing is quite frustrating because I am basically fighting JVM=
=20
implementation details I have no influence on and that are possible=20
subject to change. It makes me consider to investigate Graal again.=20
Maybe I can get further with the help of AI here. Also I may have to=20
consider an change of architecture away from the callsite view to a=20
receiver view for the cold path. There are still a few things to=20
investigate. Will this influence beta-1... probably not. If I have to do=
=20
a really really big change maybe. But then I will of course start a=20
Thread here. I may for example change how the callsite for indy are=20
generated to get away from the specialized types. Maybe even a Handle=20
calling reflection. Promoting from cold to hot path implementation is=20
also not easy, since everything I add will potentially make the cold=20
path slower.

bye Jochen

On 7/4/26 08:57, Paul King wrote:
> Hi folks,
>=20
> Thanks to everyone for helping get out the last round of releases.
>=20
> In Jira, I renamed the next Groovy 6 release to be 6.0.0-beta-1.
> Depending on any feedback we get, we can always rename back to
> alpha-3, or if we decide that we are in fact feature complete, we
> could push for RC-1 instead.
>=20
> There are a few open PRs and a few open GEPs we should discuss as we
> lock those in for Groovy 6/7 versions. I'll send those as separate
> emails over the coming week. The optimistic plan would be a beta-1 in
> a few weeks, then RC-1 a few weeks after that, and then 6 GA a few
> weeks after that. But obviously, more versions and/or more time
> between versions if we need it.
>=20
> We have also been in discussions with JetBrains about working with
> them to improve the Groovy plugin for IDEA. I think that is something
> we should try to do next once 6 looks locked down (which it is or is
> close).
>=20
> I also have draft reference implementations for groovy-ginq-sql (SQL
> and jOOQ extensions for groovy-ginq) and for switch pattern matching,
> but they are things I think we should target for Groovy 7. That is two
> of the "seeking feedback" emails I hope to write soon but feel free to
> look at the draft PRs in the meantime if you want.
>=20
> Cheers, Paul.