On 18.12.2017 01:01, MG wrote:
Just came across this as an example where using Groovy 2.4.6 invokedynamic seems to have been much slower than the older callsite caching mechanism: https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)
It is a chicken-egg problem. We still need to optimize indy in some areas. But this does not happen if no users care to give detailed reports which we can base optimizations on. They on the other hand simply switch to static compilation or old callsite caching then. So in the end there is no optimization, because optimizations tend to inflate and complicate code.
And for the old callsite caching there is another part... I highly doubt it is still well working with JDK9. Worse, I do not see how this can be made work efficiently under JDK9. The preferred way in JDK9 is invokedynamic after all. And while they (JDK developers) tend to increase the capabilities of invokedynamic, it is the opposite story for reflection (deep reflection, callsite sensitive rights made even worse through modules, ...)
So frankly I do not see much of a future for the old callsite caching bye Jochen
