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