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

Peter Levart peter.levart at gmail.com
Sat May 25 07:52:54 PDT 2013

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.

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

Regards, Peter

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

More information about the lambda-dev mailing list