hg: lambda/lambda/jdk: Additional spec tweaks for lambda metafactory

Peter Levart peter.levart at gmail.com
Sat May 25 02:44:05 PDT 2013


Hi Brian,

I just want to express an observation that I had when I was playing with 
LambdaMetafactory trying various ways to cache CallSite objects or proxy 
classes generated by it. I noticed that sometimes caching is not needed 
but sometimes it would be beneficial. When I tried to capture those 
situations I found that the caching logic had to deduce whether there is 
a single capture site generated by javac per target method or there 
could be two (serialize-able lambdas) or many of them (method 
references). The only way my logic could deduce this information was 
indirectly by interpreting the target method names and looking for know 
patterns in them and by interpreting the serializability flag in context 
of current javac compilation strategy. Now the point of 
LambdaMetafactory is to decouple the javac compilation strategy from the 
implementation of capturing and lambda creation logic to make both of 
them independent from each other and be able to evolve independently (in 
particular to enable old class files be compatible with newer runtimes).

In light of that, what do you think of another boolean flag for 
LambdaMetafactory (or one or two bits in existing flags argument) that 
could be interpreted as a hint from javac telling metafactory the number 
of capture sites per target method. One bit could tell there is one/more 
than one, but 2 bits could tell there is one/two/three/more than three. 
With such hint metafactory could reliably decide whether caching should 
be attempted or not. Currently this additional info would be ignored, 
but may be needed in the future.

Regards, Peter

On 05/24/2013 08:17 PM, brian.goetz at oracle.com wrote:
> Changeset: 0e779ee14d4d
> Author:    briangoetz
> Date:      2013-05-24 14:16 -0400
> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0e779ee14d4d
>
> Additional spec tweaks for lambda metafactory
>
> ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>
>



More information about the lambda-dev mailing list