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

[Remi Forax]

On 03/04/2013 03:26 PM, Brian Goetz wrote:
> 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
> optimizations."

One solution is, if the lambda is serializable, to emulate invokedynamic
using constant method handles stored in static final fields, thus 
shareable .
But this make the translation scheme for javac ugly.

Another solution is to have an API to query already existing CallSite 
objects,
so the invokedynamic in $deserializeLambda$ will effectively share the 
same lambda proxy.
It's a good question for the JSR 292 EG :)

Rémi

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