No,

Our image is not 47 MB… more like 28.

My understanding is:
        -> Cog works with “pages” (is that the term?) of memory.
        -> if a page is empty, it gets cleaned up and does not cost space when 
saving.
        -> if there is some object still allocated, the whole page will be 
saved (partly empty)

Not sure if that is completely right, but it explains why the image with 
lots of objects allocated new can shrink again, while the 47MB never shrinks, 
even though the
image for sure is much smaller.

=> what is missing is a “cleanup” phase that sweeps together all the half-empty 
pages.

What is fun is that we now ship a 47MB image and nobody ever complains. (or 
even asks)

        Marcus

> On 16 Feb 2017, at 16:07, Sven Van Caekenberghe <[email protected]> wrote:
> 
> What Ben says that he thinks it might already be solved.
> 
> Maybe not on all platforms.
> 
>> On 16 Feb 2017, at 15:59, denker <[email protected]> wrote:
>> 
>> Yes, this has to be solved on the VM level and will be read when it is ready.
>> The release should bot be hold up due to this, therefore I removed the 
>> milestone.
>> 
>>> On 16 Feb 2017, at 15:50, Ben Coman <[email protected]> wrote:
>>> 
>>> @Marcus, I was reviewing this issue before I noticed you flipped the
>>> milestone from Pharo 6.0 to Later.
>>> 
>>> But is it solved already?
>>> In a fresh image 47.7MB in size
>>> I did the following a bunch of times to grow the image file to 400MB
>>>  o ifNil: [o := OrderedCollection new].
>>>  100 timesRepeat: [ o add: (Array new: 100000) ].
>>>  Smalltalk saveSession
>>> 
>>> then I did this
>>>  o := nil.
>>>  Smalltalk saveSession.
>>> 
>>> and the image file returned to 47.7MB.
>>> 
>>> Version info...
>>> Linux Debian 8 Jessie 32-bit
>>> Latest update: #60391
>>> CoInterpreter VMMaker.oscog-eem.1855 uuid:
>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
>>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid:
>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
>>> https://github.com/pharo-project/pharo-vm.git Commit:
>>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22
>>> +0200 By: Esteban Lorenzano <[email protected]> Jenkins build #589
>>> 
>>> https://pharo.fogbugz.com/f/cases/17240/Spur-When-saving-an-image-it-never-shrinks
>>> 
>>> cheers -ben
>>> 
>> 
>> 
> 
> 


Reply via email to