Serialization opt-in syntax (again)

Remi Forax forax at
Tue Oct 2 01:55:58 PDT 2012

On 10/02/2012 06:26 AM, Brian Goetz wrote:
> Unfortunately I do not believe the cost is negligible. 

I think the opposite.

>  One of the downsides of our translation approach is that 
> serialization overhead is higher.  For inner classes, it is just a 
> matter of tagging the class as serializable, which is negligible.  But 
> for our approach, we would have to carry more information in the 
> lambda itself, and the "must be serializable" constraint also rules 
> out several possible metafactory approaches.


You're talking about the method handle approach, as I already says, 
being serailizable implies two things.
You need to be able to have a runtime description of the lambda, this 
object is created once for all lambdas,
so it has a small footprint cost but not more than the additional 
footprint cost we have because we use a metafactory
(the bootstrap method + callsite initialization has an overhead compare 
to a classical Java call).
Then you need to access to the bounded values, the value copied from the 
current scope, there is two ways
to deal with them, either we stored them as a reference in the SAM proxy 
and then we teach the VM to inline the value
when the method is called (John Rose has just landed a patch for that in 
Hotspot) or you can bound the parameter
to the method handle and we need to crack the method handle to get the 
values back when you want to serialize
(again, this is not hard to do that with the current implementation).

Whatever the way you choose, there is no runtime cost at all when you 
call the lambda if there is no
bound values or if the VM is able to see that the lambda doesn't escape 
(if the VM inlines together
the site when you create the lambda and the site you call the lambda.

If the lambda escape, it means you store it in a field somewhere, so the 
users use the stream API
ou Doug's API by example, and we know that these APIs creates objects 
too so the overhead of
serailizable lambdas will not be that visible (my gut feeling is that 
you will not see the overhead at all).

>  Also, in our approach, serializable lambdas require a lot of 
> additional static footprint in the capturing class to deal with the 
> potential security issues. 

Not a lot, and this static values are stored in an object once.

>  Also, I believe that serialization really needs to be somethign users 
> opt explicitly into.  Foisting transparent serializaxbility on users 
> seems rude.

It just works, is it that rude ?
And if users don't want a serializable lambdas they can still use inner 

> Overall I do not see this as a realistic option.

I think you're wrong.


> On Oct 1, 2012, at 1:10 PM, Zakharov, Vladimir wrote:
>> Excellent question. What is the cost and under what circumstances 
>> will it be incurred? I suspect, based on our experience with GS 
>> Collections, where all interfaces extend Serializable (including 
>> Predicates, Functions, etc.), the practical cost would be negligible.
>> *The Goldman Sachs Group, Inc. All rights reserved*.
>> See important risk 
>> disclosures, conflicts of interest and other terms and conditions 
>> relating to this e-mail and your reliance on information contained in 
>> it.  This message may contain confidential or privileged 
>> information.  If you are not the intended recipient, please advise us 
>> immediately and delete this message.  
>> See further information on 
>> confidentiality and the risks of non-secure electronic communication. 
>> If you cannot access these links, please notify us by reply message 
>> and we will send the contents to you.
>> *From:*lambda-spec-experts-bounces at 
>> <mailto:lambda-spec-experts-bounces at> 
>> [mailto:lambda-spec-experts-bounces at]*On Behalf 
>> Of*Kevin Bourrillion
>> *Sent:*Monday, October 01, 2012 12:12 PM
>> *To:*Brian Goetz
>> *Cc:*lambda-spec-experts at 
>> <mailto:lambda-spec-experts at>
>> *Subject:*Re: Serialization opt-in syntax (again)
>> On Mon, Oct 1, 2012 at 8:57 AM, Kevin Bourrillion <kevinb at 
>> <mailto:kevinb at>> wrote:
>>     And AFAIK, having all lambdas be serializable and having no
>>     lambdas be serializable are still not considered viable. So we're
>>     really in a tough spot.
>> Actually, given the horrors we're discussing here, let's be sure 
>> about this.  If all lambdas were serializable it would be a get out 
>> of jail free card for this design conundrum, so I must ask:  are we 
>> all satisfied that we have accurately quantified just/how/ bad it 
>> would be performance-wise?  If so: how bad?
>> --
>> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at 
>> <mailto:kevinb at>

More information about the lambda-spec-experts mailing list