On 16 Feb 2017, at 16:16, denker <marcus.denker@inria.fr> wrote:
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)
Yeah, that proves it is not such a big deal, today. But still, we have to fix this discrepancy between 28 and 47. Is the 'release cleanup' done on this image each time ?
Marcus
On 16 Feb 2017, at 16:07, Sven Van Caekenberghe <sven@stfx.eu> 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 <marcus.denker@inria.fr> 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 <btc@openinworld.com> 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 <estebanlm@gmail.com> Jenkins build #589
https://pharo.fogbugz.com/f/cases/17240/Spur-When-saving-an-image-it-never-s...
cheers -ben