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

[Brian Goetz]

Its a good problem to kick down the road.  When/if we switch to a 
class-per-SAM instead of class-per-callsite implementation of lambda 
conversion, the issue goes away.

On 3/4/2013 1:38 PM, Remi Forax wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>
>