groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: About the native lambda
Date Fri, 22 Dec 2017 13:52:53 GMT


you can have a look at Elasticsearch’s Painless scripting language. It has both variants:
Static Lambdas and dynamic Lambdas on DEF type (code calls a method on the def type that takes
a lambda/function ref). In the latter case the actual call to the method taking the lambda
is delegated through the standard invokedynamic we use for DEF (the is the
main bootstrap entry point for all dynamic stuff involving DEF type, it creates several caches
like a polymorpic for most cases, a megamporphic using classvalue and for 2 types operators
it uses a monomorphic cache for scaling reasons).


If you call a method on DEF where you give it a lambda or method reference, nothing is known.
In that case it goes through the above “master bootstrap” where it resolves the correct
method according to types and the just calls the LambdaBootstrap without invokedynamic from
Java code (it is just a call to the lambda bootstrapper):


It just uses a different LambdaBootstrapper (LAMBDA_BOOTSTRAP_HANDLE), because starting with
Java 9 the default one - shipped with Java - got more picky and did not work for all required
type conversions. So we have our own LambdaMetaFactory (but that’s unrelated, in Java 10
the bugs should be fixed and we may fall back to the Java one):


This one uses a cool trick to do the type conversions – a second invokedynamic inside the
generated lambda functional interface method implementation (that does the type conversion
for us with “as Type”), see:





If you have a method call taking a lambda where everything is known (the “Java case”),
it writes a standard invokedynamic like Java does in the generated bytecode:


One place for lambda is here:

(there are others for static complilation, e.g. for method refs).


That’s the “default java case”, just with our own bootstrapper!


We are currently writing a blog post about this, but it’s hard to explain for somebody with
no knowledge about bytecode and how lambdas work in a single 5 page blog post!





Uwe Schindler 

ASF Member, Apache Lucene PMC / Committer

Bremen, Germany


From: Remi Forax [] 
Sent: Friday, December 22, 2017 12:53 PM
To: dev <>
Subject: Re: About the native lambda




De: "Jesper Steen Møller" < <> >
À: "dev" < <> >
Cc: <> 
Envoyé: Vendredi 22 Décembre 2017 11:26:06
Objet: Re: About the native lambda


On 22 Dec 2017, at 10.48, Daniel.Sun < <>
> wrote:

      The problem I am trying to resolve is how to get the method's name
and descriptor? [2] It seems the type flow analysis have to rely on the
existing static compilation...


There is no short cut possible here: You need full static analysis to make lambdas Java-compatible
and emit the right invokedynamic calls. And the type inference is really complicated w.r.t


You can read about it here:




There is a "shortcut" possible, like usually with a dynamic language, you can postpone the
creation until you have enough data.


So you create a lambda object but not by emiting the invokedynamic on the LambdaMetaFactory,
but by creating a new Lambda object (it can be the same object as a Closure or not) and when
you need to coerce it to a functional interface at that time you call the invokedynamic on
the LambdaMetaFactory.


To be able to call the LambdaMetaFactory, the Lambda object need to store a MethodHandle on
a static method (a constant method handle) and the Lookup object used to create the method





View raw message