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

[Remi Forax]

On 05/25/2013 11:44 AM, Peter Levart wrote:
> 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).

I don't understand how knowing if it's a method reference or not, 
enables better caching.

And for the long term, the idea is to use the proxy based on method 
handle implementation,
for several reasons, one of them is that lambda forms
(the way method handles are encoded in the VM)
already have a caching mechanism.

>   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

Rémi

>
> 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
>>
>>
>