<div dir="ltr">Hi Chris,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 7:20 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eliot,<br>
<br>
It sounds like you selected 'flush cached versions and ancestry' from<br>
the Repository menu of the Monticello Working Copy browser.<br>
<br>
That's something that you would only want to do for a production<br>
deployment image where you aren't planning to do any more development<br>
in.  It saves memory on ancestry while providing a dynamic (albeit,<br>
slow) means of loading it back on the rare case that one would need to<br>
do that in the production image ever again.  The PointerFinder is not<br>
sensitive enough for proxies, so using it ends up agitating them into<br>
reification, forcing the dynamic reload of ancestry like you<br>
experienced.<br>
<br>
What you want is simply, "flush cached versions" and then you'll never<br>
have that issue.<br></blockquote><div><br></div><div>Can you explain?  How does this create the issue?  Why have an item like "flush cached versions and ancestry" if its dangerous.  The implication of :cached" is that the information can be rebuilt when required.  The ancestry is out there in the .mcz files.  I don't understand what's going on here.  feels like a bad design decision.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
 - Chris<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Jan 18, 2018 at 5:24 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> Hi All,<br>
><br>
>     I've been experiencing image save slowdowns recently and finally my work<br>
> image reached 1.%Gb and I thought I better take a look:<br>
><br>
> Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*<br>
> -rw-r--r--@ 1 eliot  staff    28M Jan 18 12:47 SpurWork64.changes<br>
> -rw-r--r--@ 1 eliot  staff   1.6G Jan 18 12:48 SpurWork64.image<br>
> -rw-r--r--@ 1 eliot  staff    28M Jan 18 12:03<br>
> save/SpurWork64-2018-01-18.<wbr>changes<br>
> -rw-r--r--@ 1 eliot  staff   1.5G Jan 18 12:03<br>
> save/SpurWork64-2018-01-18.<wbr>image<br>
><br>
> I ran a space analysis and found that Bitmap and ByteArray were the top two,<br>
> so I looked for large Bitmaps.  I found three that fit this criterion:<br>
><br>
><br>
>     Bitmap allInstances select: [:bm| bm size >= 1000000 and: [bm ~~ Display<br>
> bits]]<br>
><br>
> I inspected the three and did a chase pointers on one of them.  As I did<br>
> that suddenly<br>
> a) the inspector on the Array became empty (still an array but zero<br>
> elements)<br>
> b) the progress bar for Downloading FlexibleVocabularies-who.NN appeared<br>
><br>
> I interrupted this and did a very cursory stack examination. Some object had<br>
> not understood isLiteral and from there what looked like an attempt to turn<br>
> this stub into a real object caused FlexibleVocabularies-who.NN to start to<br>
> download.<br>
><br>
> I threw away the debugger, ran the GC and suddenly all my free space was<br>
> back.  So now on disc I have<br>
><br>
> Sisyphus.Cog$ ls -lh SpurWork64.* save/SpurWork64-*<br>
> -rw-r--r--@ 1 eliot  staff    28M Jan 18 15:17 SpurWork64.changes<br>
> -rw-r--r--@ 1 eliot  staff    57M Jan 18 15:17 SpurWork64.image<br>
> -rw-r--r--@ 1 eliot  staff    28M Jan 18 12:03<br>
> save/SpurWork64-2018-01-18.<wbr>changes<br>
> -rw-r--r--@ 1 eliot  staff   1.5G Jan 18 12:03<br>
> save/SpurWork64-2018-01-18.<wbr>image<br>
><br>
> What is going on here?  There seems to be a very bad storage leak.  Can we<br>
> please discuss this?  This doesn't seem like healthy behaviour at all :-)<br>
><br>
> _,,,^..^,,,_<br>
> best, Eliot<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>