Re: Building Groovy

[MG]

Hmmm, I don't know if Paul has some comeback, but to me you make a very 
convincing point...

In that case the best way forward to me seems to be to
1) Ask non-@CompileStatic Groovy users who can afford the time to switch 
to the invoke dynamic variety of the Groovy jars and report back on 
performance issues (tests that run much slower, etc)
2) Add a clearly visible message to the Groovy distribution download 
section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic 
only, and again ask for people to use indy now & give feedback if code 
seems to be unusally slow
3) Start a competition who can come up with the most unexpectedly worst 
performing piece of Groovy indy code... ;-)
(To be quite honest, I am wondering myself how invoke dynamic can be 
slower than the older, homebrewn approach, even if that is highly 
optimized - it seems to me like it should be a bit like a software 
renderer going up against a GPU...)


Cheers,
mg


On 18.12.2017 15:54, Jochen Theodorou wrote:

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

Re: Gradle build updates

[Cédric Champeau]

No there is not. But it should be pretty easy to do so, using Gradle shadow
plugin for example.

2017-12-18 16:59 GMT+01:00 :

> "The "all" sources is still produced. But there's no all jar anymore."
>
>
>
> Is there a way to get back to being able to produce an all jar?  I
> actually leverage the embeddable jar for embedding in another OSGi bundle.
> I was humming along with adding Groovy 2.5 support through beta2 and now it
> seems I would have to retool my single jar handling to deal with a number
> of module jars instead.
>

RE: Gradle build updates

[eric.milles]

"The "all" sources is still produced. But there's no all jar anymore."

Is there a way to get back to being able to produce an all jar?  I actually 
leverage the embeddable jar for embedding in another OSGi bundle.  I was 
humming along with adding Groovy 2.5 support through beta2 and now it seems I 
would have to retool my single jar handling to deal with a number of module 
jars instead.

Re: Building Groovy

[Jochen Theodorou]

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