Serialization opt-in syntax (again)

Remi Forax forax at
Sun Sep 30 11:16:51 PDT 2012

On 09/30/2012 03:59 PM, Brian Goetz wrote:
> On Sep 30, 2012, at 9:04 AM, Remi Forax wrote:
>> On 09/29/2012 11:14 PM, Brian Goetz wrote:
>>>>> Brian, do you have data about the supplementary cost of creating Serializable lambda ?
>>> Sadly I do not  yet, and may not for a while.  But I know that there will be a nonzero footprint and capture cost, and it imposes some additional hurdles on some VM optimizations we want to do.  I think that's all the information we will ahve for a while, but I think we have to go on the assumption that the cost will be enough that "make all lambdas serializable" is not a very good choice.
>> I've done some tests asking the VM to dump the assembly code so see the impact of having lambdas serializable or not.
> Given that we don't have an implementation yet, not sure how you could have done this.

for the inner-class implementation as you said below you have already 
enough information to serialize bound values,
for the method handle implementation, you have two ways to implement it, 
either you use insertArguments when
you create the method handle and you crack the method handle to get the 
values back
or the proxy object stores the bound values in an Object array along 
with the method handle, the values in the array are unboxed when the 
method handle is called and you teach the VM to know that the Object 
array is constant (stable).
Thus for all ways to implement it, the fact that the lambda is 
serializable only add a reference to an object that store the 
information that are passed to the lambda metafactory.

>> First, if the lambda is constant i.e. don't capture any states, then the lambda is created once and reused,
> Yes, that's the easy case.

yes, and the other cases are also detailed in my previous email.

> Also, note that our current translation scheme -- where we generate bytecode for each lambda -- is more serialization friendly than the alternate scheme, where we generate a single wrapper for each SAM and invoke the behavior as an MH.  In the latter case, we have to keep around a lot more information that otherwise would have been thrown away by the MF, such as the captured arguments bound with insertArguments.

see above.

> It is NOT going to be free in most cases.  We can do our best to make it small.

Spending an extra mov when you see that just after the VM has spill 
another variable thus also spend an extra move,
is something that I call free, at least free enough to not worth to 
bother users about that.


More information about the lambda-spec-experts mailing list