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

[Remi Forax]

On 05/25/2013 04:52 PM, Peter Levart wrote:
>
> On 05/25/2013 02:58 PM, Remi Forax wrote:
>> 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.
>
> Knowing whether the proxy is being constructed for given target method 
> at one capture site only (lambda expression) or at possibly several 
> capture sites (method reference) can enable better caching, because 
> for a singe capture site per target method, no caching is needed 
> (considering current proxy generation strategy), since the caching is 
> performed at single capture site by invokedynamic (1st level cache) 
> already. For several capture sites of the same (SAM/target method) 
> pair, the proxy factory could be cached (in common 2nd level cache) 
> and reused.

The cache you propose is usually not a good idea. It will blindly cache 
a lot of lambda proxy classes, you also need a global lock, for a very 
little reward. And even if you can share proxy classes for serializable 
lambda by example, it's useless if the lambda is not serialized.
That's why by example the VM doesn't cache the same constant method 
handle shared by different invokedynamic opcodes.

>
>> 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.
>
> After posting the message, I realized that this knowledge (about # of 
> capture sites per target method) may not be needed in the future, 
> since with proxy generation strategy that uses methods handles for 
> invoking target methods, caching of proxy factories could be 
> effectively performed even for lambda expressions, because proxy 
> factory for same SAM could be cached and reused even across different 
> target methods.

yes :)

>
> Regards, Peter

cheers,
Rémi

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