[8] Review request for 8008770: SerializedLambda incorrect class loader for lambda deserializing class

Brian Goetz brian.goetz at oracle.com
Mon Mar 4 06:26:05 PST 2013

You are correct.  This is less than ideal, but allowable, and we're 
treating this as a quality-of-implementation issue.  The solution would 
be to "outline" both capture sites into a private method and replace 
them both with a call to that method; then they would share the 
invokedynamic call site.  It's on the list of "possible future 

On 3/4/2013 3:18 AM, Peter Levart wrote:
> Hi Robert,
> I noticed that when the same VM is used both for evaluating a lambda
> expression (producing a SAM instance) and for de-serializing a
> previously serialized SAM instance representing the same lambda
> expression, two distinct SAM proxy classes are generated (and
> consequently, even non-capturing lambdas come out as two distinct
> instances). I believe this is because there are two places where
> LambdaMetafactory is called - the "indy" call generated by javac in the
> place of a lambda expression and one in the "$deserializeLambda$" method
> of the capturing class - and each call produces a distinct lambda
> factory with a distinct generated proxy class.
> Do you feel that this situation is rare and/or that maintaining a cache
> of "CallSite" objects per "altMetaFactory" request parameters would
> actually present a greater overhead than generating two classes in such
> scenarios?
> Regards, Peter
> On 02/25/2013 06:24 PM, Robert Field wrote:
>> Please review the fixes for CRs:
>>           http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008770
>> Webrev:
>>           http://cr.openjdk.java.net/~rfield/8008770_2/
>> Thank,
>> Robert

More information about the lambda-dev mailing list