groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <jes...@selskabet.org>
Subject Re: Groovy 3 release
Date Sun, 27 May 2018 18:35:15 GMT

> On 27 May 2018, at 20.25, Jesper Steen Møller <jesper@selskabet.org> wrote:
> 
> On 27 May 2018, at 14.44, Daniel.Sun <sunlan@apache.org> wrote:
>> 
>> Native lambda is only available on master branch, and it is only be enabled
>> under static compilation.
>> 
> 
> I had a chance to examine the current implementation. It uses a LambdaMetafactory to
bootstrap (i.e. generate inner class) access to the doCall of the generated lambda/closure
object. That means TWO classes per lambda definition (in use), and two objects generated at
every lambda use. I haven't made any benchmarks, but we should be able to do better:
> 1) Don't distinguish between lambdas and closures.
> 2) If the closure's instantiation is targeting a functional interface, add the expected
identified functional interface to the closure class, and implement that in the closure class
(bridging the single interface method into the doClass) call.
> 3) If using compilestatic, we don't need any type conversions to match the callee.

4) Added bonus: Even if using dynamic, sometimes we may use our "invested" bridge method so
we could avoid creating a proxy.
After all, even a lot of dynamic Groovy ends up calling something which is well known in advance.

-Jesper


Mime
View raw message