On 05.01.26 23:12, Jonny wrote:
Hey, James. I took that repository out for a spin today. I posted my
findings at
https://github.com/apache/grails-core/issues/15293#issuecomment-3712253386 <https://github.com/apache/grails-core/issues/15293#issuecomment-3712253386>.
In short, the profiler does indicate that most of the time is getting
consumed in calls to |java.lang.invoke.Invokers$Holder#linkToCallSite|.
That would suggest that there's not much low-hanging fruit to optimize
away beyond addressing the problems with InvokeDynamic. It also renders
me somewhat skeptical that switching to @CompileStatic would address the
root problems in this case.
Apologies that I don't have anything more useful to offer, but I figured
I should at least share what I found.
Is this the same as
https://github.com/openjdk/jdk/blob/jdk-19%2B0/src/java.base/share/classes/java/lang/invoke/Invokers.java#L579
?
This only gets the lambda form for what is "target type" in our logs for
indy.. of course if that really is depending on the callsite, then we
have a ton of different ones. If that is causing a problem we would have
to rethink how we compile dynamic Groovy. Then a println("Hello World")
should maybe not be compiled as a callsite for (String)Object, but as
(Object)Object, well actually as (Object,Object)Object for the implicit
this. Except for the usage of primitives (int for example) that would
not be a big change. But it means to change the part that writes the
callsite invokedynamic instruction.
And of course if this is called also for other cases the change may not
have the effect this promises.
As for @CompileStatic. CompileStatic does not use indy where it is fully
implemented. Switching would therefore solve the problem where it is
implemented and well... where it is not used by Java. But even if used
in the same way as Java, we would have a different type of ClassSite
object (ConstantCallSite) which would also perform differently.
bye Jochen
