Hi Eliot,

It sounds like you selected 'flush cached versions and ancestry' from
the Repository menu of the Monticello Working Copy browser.

That's something that you would only want to do for a production
deployment image where you aren't planning to do any more development
in.  It saves memory on ancestry while providing a dynamic (albeit,
slow) means of loading it back on the rare case that one would need to
do that in the production image ever again.  The PointerFinder is not
sensitive enough for proxies, so using it ends up agitating them into
reification, forcing the dynamic reload of ancestry like you
experienced.

What you want is simply, "flush cached versions" and then you'll never
have that issue.

 - Chris

On Thu, Jan 18, 2018 at 5: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
>
>
>