groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re:
Date Tue, 05 Jul 2016 13:06:07 GMT
2016-07-05 15:03 GMT+02:00 Remi Forax <forax@univ-mlv.fr>:

> Just a note,
> Java has exactly the same bug when loading a class (at least Java before
> 9), when a class is not found, the classloader throw a
> ClassNotFoundException which may be catched by another classloader down the
> stack.
>
> The JIT (c2) even try to optimize such case by avoiding to fill the stack
> trace and transforming the throw/catch to a goto, but usually, the chain of
> callers is to deep to be optimized correctly :(
>
> In Gradle we try to workaround this with a `CachingClassLoader` that
caches misses. But it cannot cover all cases, and yes, this is a terrible
idea too, responsible for a lot of the classloading slowness in Gradle.

> Rémi
>
> ----- Mail original -----
> > De: "Jochen Theodorou" <blackdrag@gmx.org>
> > À: dev@groovy.apache.org
> > Envoyé: Mardi 5 Juillet 2016 13:52:18
> > Objet: Re:
> >
> >
> >
> > On 05.07.2016 10:05, Thibault Kruse wrote:
> > > Hi,
> > >
> > > (I tried sending this mail before, failed so far)
> > >
> > > This is about using @CompileStatic inside core Groovy code.
> > >
> > > The analysis of gradle plugins by Cedric revealed a potential
> > > problem with dynamic Groovy:
> >
> > It is no new problem, it is, as Cedric said, a "terrible design
> > decision"... done somewhen long ago... 10+ years ago. Back then it made
> > more sense, because back then the MetaClass was always doing the actual
> > invocation. With callsite caching this changed.... but the time back
> > then was not used to correct that mistake.
> >
> > [...]
> > > Now I am wondering, since parts of Groovy itself are written in
> > > Groovy, and @CompileStatic is not much used in side Groovy itself,
> > > does core Groovy suffer from performance issues due to the same reasons
> > > as well?
> >
> > that is not easy to answer... the compiler is in Java, but transforms
> > might be in Groovy, so there is potential, even though it is not much.
> > Then the runtime core is in Java, but we are doing dynamic invocations
> > inside, from Java code at some points.
> >
> > No, in total I must say it depends on your use case. We have some paths,
> > that may suffer from that and many paths that do not. if you for example
> > test against a builder, then you would of course get the problem. Method
> > invocations for example do not have the problem as much... properties
> > tend to have problems, but if you want to write a benchmark, you cannot
> > use a local variable or field in the same class. You have to access the
> > property of something that is not "this". And then you should notice
> > terrible performance, because afaik we do not cache property access at
> > all in non-indy.
> >
> > bye Jochen
> >
>

Mime
View raw message