Serialization opt-in syntax (again)
forax at univ-mlv.fr
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*.
>> Seehttp://www.gs.com/disclaimer/global_emailfor 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.
>> Seehttp://www.gs.com/disclaimer/emailfor 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 openjdk.java.net
>> <mailto:lambda-spec-experts-bounces at openjdk.java.net>
>> [mailto:lambda-spec-experts-bounces at openjdk.java.net]*On Behalf
>> Of*Kevin Bourrillion
>> *Sent:*Monday, October 01, 2012 12:12 PM
>> *To:*Brian Goetz
>> *Cc:*lambda-spec-experts at openjdk.java.net
>> <mailto:lambda-spec-experts at openjdk.java.net>
>> *Subject:*Re: Serialization opt-in syntax (again)
>> On Mon, Oct 1, 2012 at 8:57 AM, Kevin Bourrillion <kevinb at google.com
>> <mailto:kevinb at google.com>> 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 google.com
>> <mailto:kevinb at google.com>
More information about the lambda-spec-experts