On Thu, Jan 18, 2018 at 3:24 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi All,

I've been experiencing image save slowdowns recently and finally my work image reached 1.%Gb and I thought I better take a look:

Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*
-rw-r--r--@ 1 eliot staff 28M Jan 18 12:47 SpurWork64.changes
-rw-r--r--@ 1 eliot staff 1.6G Jan 18 12:48 SpurWork64.image
-rw-r--r--@ 1 eliot staff 28M Jan 18 12:03 save/SpurWork64-2018-01-18.changes
-rw-r--r--@ 1 eliot staff 1.5G Jan 18 12:03 save/SpurWork64-2018-01-18.image

I ran a space analysis and found that Bitmap and ByteArray were the top two, so I looked for large Bitmaps. I found three that fit this criterion:

Bitmap allInstances select: [:bm| bm size >= 1000000 and: [bm ~~ Display bits]]

I inspected the three and did a chase pointers on one of them. As I did that suddenly
a) the inspector on the Array became empty (still an array but zero elements)
b) the progress bar for Downloading FlexibleVocabularies-who.NN appeared

I interrupted this and did a very cursory stack examination. Some object had not understood isLiteral and from there what looked like an attempt to turn this stub into a real object caused FlexibleVocabularies-who.NN to start to download.

I threw away the debugger, ran the GC and suddenly all my free space was back. So now on disc I have

Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*
-rw-r--r--@ 1 eliot staff 28M Jan 18 15:17 SpurWork64.changes
-rw-r--r--@ 1 eliot staff 57M Jan 18 15:17 SpurWork64.image
-rw-r--r--@ 1 eliot staff 28M Jan 18 12:03 save/SpurWork64-2018-01-18.changes
-rw-r--r--@ 1 eliot staff 1.5G Jan 18 12:03 save/SpurWork64-2018-01-18.image

What is going on here? There seems to be a very bad storage leak. Can we please discuss this? This doesn't seem like healthy behaviour at all :-)

_,,,^..^,,,_
best, Eliot

My behavior was different. Also, my image is a bit smaller (300mb).

I ran you check for large Bitmaps, and found 3 (all length 1924440).

#chasePointers on each of them from the inspect chased them back to the inspecter. So I ran:

(Bitmap allInstances select: [:bm| bm size >= 1000000 and: [bm ~~ Display bits]]) anyOne chasePointers

This goes away for a long time - I got bored, interupted it, and inspected the large bitmaps again. This time, I only found 1.

After saving the image, the image size did not drop (still 326mb).

Image and VM is undoubttedly behind yours, but here it is:

Image

-----

C:\Squeak\Viz Landscape 6.0 64\hmm-64bit.1.image

Squeak6.0alpha

latest update: #17647

Image format 68021 (64 bit)

Virtual Machine

---------------

C:\Squeak\Viz Landscape 6.0 64\Squeak.exe

Croquet Closure Stack VM [StackInterpreterPrimitives VMMaker.oscog-eem.2188]

Win32 built on Apr 12 2017 09:46:07 GMT Compiler: 4.2.1 Compatible Clang 3.9.1 (tags/RELEASE_391/final)

platform sources revision VM: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Apr 12 10:50:48 2017 +0200 $ Plugins: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

StackInterpreter VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017

-cbc