groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re:
Date Tue, 05 Jul 2016 13:03:44 GMT
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
:(

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