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