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

Mariano Martinez Peck marianopeck at gmail.com
Fri Dec 2 19:33:03 UTC 2011


On Fri, Dec 2, 2011 at 8:18 PM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:

>
>
>>> 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 ]).
>
>
of course it doesn't make sense to do a return there. I was just an
example, imagine another place where there is a blockclosure I want to
serialize and there is a return inside.




> 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
>
>


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


More information about the Squeak-dev mailing list