groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <>
Subject Re: About the native-lambda branch
Date Fri, 12 Jan 2018 12:22:22 GMT
Hi Jochen and Daniel

> On 12 Jan 2018, at 12.48, Jochen Theodorou <> wrote:
> Am 12.01.2018 um 04:05 schrieb Daniel Sun:
>> Hi Nathan,
>>> What's will the differences be between closures and lambdas?
>> The native lambda will have better performance than closure. In addition,
>> native lambda, which conforms to Java specification,  is less versatile than
>> closure, which is really powerful...
> but I think you should then not use the closure inner class mechanism. I had a bit a
look at your code, but there is a ton of things missing. I did also not understand the innclass
attribute visit... I thought you need that only to enable reflection to find your inner classes.
MethodHandles.Lookup is no such thing. And then I would also question the early transformation
you do where you store the lambda as body in a method node... which resides in the current
class and which may have a name conflicting with an existing name... and a name check is something
I would not do in that ast builder. In fact I would do this logic just before or even in ACG.
Otherwise you will always have trouble with code that transforms the lambda expression. And
then again we miss totally the handling of local variables, not in the lambda. And actually
there is a performance related decision to do here. if we follow the closure logic, there
will be a wrapper containing the value of the local variable, which is then used in the lambda.
This costs. Not much, but it does. Since in Java you have only quasi final variables allowed,
you do not need any wrapper. Not using the wrapper means less Closure implementation code
we can use. But this wrapper also has quite special handling in many areas, like the VariableScopeVisitor.
Oh yes... should you go with one inner class for all lambdas, then you have to add bridge
methods to be able to access private fields in the outer class.

I don't think we need to generate bridge classes at all. I'm not sure if you are familiar
with how lambdas are implemented by javac, but they also uses a method for each lambda expression,
and capture the rest at indy time. Javac alsot differentiates the lambda implementatoin function
based on what is captured: The lambda method is an instance method if it captures anything
nonstatic, otherwise it can be a static method (and thus possibly recycled).

For capturing locals, it would be optimal to do the same "effectively final" logic similar
to what Java does, so we could simply capture the value itself.
If we couldn't guarantee that (which ranges from tricky to impossible), then we'd fallback
to using groovy.lang.Reference like closures do.

Am I making sense? Otherwise, it'd be better to talk "in code", I guess.


View raw message