[squeak-dev] Re: [Pharo-project] Prune stack serialization

Mariano Martinez Peck marianopeck at gmail.com
Fri Dec 2 19:18:25 UTC 2011


>
>> Is this clear or as clear as mud?
>>
>
> Much clear now. One last question. So far, then, I didn't find/think a
> scenario where serializing the whole stack (from a closure)  make sense.
> So, if I just want to serialize a closure and be able to materialize it,
> then it is *never* necessary the whole stack, in all scenarios?  or I am
> missing a case where the whole stack is needed?   I am talking only about
> when serializing closures, because if I directly serialize a MethodContext,
> it may happen that I want the whole stack (like the example I showed in
> ESUG where I serialized the whole Debugger and then I continue debugging in
> another image).
>
>
For example, would this work?

| bytes result blah |
blah := 42.
bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock:
[:a :b | (a + blah) > b. ^ blah ]).

has the return something to do with this?

Thanks


Thanks!
>
>
>>
>>
>>>
>>> Thanks!
>>>
>>>
>>> On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>>
>>>>
>>>>
>>>> On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier <
>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>
>>>>> 2011/12/2 Martin Dias <tinchodias at gmail.com>:
>>>>> > Hi folks
>>>>> >
>>>>> > In Fuel, we serialize a block closure with its state, including its
>>>>> > outerContext. This enables to serialize a sorted collection with its
>>>>> > sortBlock:
>>>>> >
>>>>> > | bytes result |
>>>>> > bytes := FLSerializer serializeToByteArray: (SortedCollection
>>>>> sortBlock: [:a
>>>>> > :b | a > b ]).
>>>>> > result := FLMaterializer materializeFromByteArray: bytes.
>>>>> > result
>>>>> > addAll: #(1 2 3);
>>>>> > yourself.
>>>>> > ---> a SortedCollection(3 2 1)
>>>>> >
>>>>> > Here the problem: the byte array is huge! (800kb) because we are
>>>>> serializing
>>>>> > unneeded context for the sort block.
>>>>> >
>>>>> > We wonder how to prune it and save time and space.
>>>>> >
>>>>> > Thanks in advance
>>>>> > Martín
>>>>>
>>>>> In the case of such clean block, there is no need of outer context
>>>>> during block execution.
>>>>> However I don't know if implementation makes it possible to ignore the
>>>>> context...
>>>>> That's more a question directed to Eliot ;)
>>>>>
>>>>
>>>> Arguably there is a bug in my closure implementation, which is that
>>>> both the receiver and the method are fetched from the outerContext.  That's
>>>> not a bug which can be fixed without a new VM/image combination and may be
>>>> something I'll look at long-term, but is something we have to live with at
>>>> the moment.  This means that you *do* have to serialize the outerContext.
>>>>  But the outerContext is used only for the receiver and method.  So you
>>>> don't need to full serialize the outerContext.  In particular you don't
>>>> need to serialize any of the outerContext's stack contents or its sender.
>>>>  This needs special handling, I guess in BlockClosure, to substitute a
>>>> suitably reduced outerContext, but it shouldn't be hard to do.  e.g.
>>>>
>>>> BlockClosure methods for: '*Fuel-serialization'
>>>> outerContextForSerialization
>>>> ^MethodContext
>>>> sender: nil
>>>>  receiver outerContext receiver
>>>> method: outerContext method
>>>> args: #()
>>>>
>>>>
>>>> BlockClosure methods for: '*Fuel-serialization'
>>>> outerContextForSerialization
>>>> ^MethodContext
>>>>  sender: nil
>>>> receiver self receiver
>>>> method: self method
>>>>  args: #()
>>>>
>>>>
>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> best,
>>>> Eliot
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20111202/041f5244/attachment.htm


More information about the Squeak-dev mailing list