On Thu, Jan 18, 2018 at 3:24 PM, Eliot Miranda <eliot.miranda at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180118/3ae6918d/attachment.html>