2016-07-05 15:03 GMT+02:00 Remi Forax <[email protected]>: > 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" <[email protected]> > > À: [email protected] > > 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 > > >
