<div dir="ltr">Hi Chris,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 19, 2018 at 10:30 AM, 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">To what unpredictability and fragility do you refer?  If you're<br>
referring to the override of DNU, then you appear to be singling out<br>
this one use of it without proposing a better alternative or<br>
complaining about other uses of it as "unpredictable".  Why?<br></blockquote><div><br></div><div>I have no objections to the proxies.  It was the presence of something for deployment that is on a user menu that freaked me out.  In fact, if I understand it correctly flush ancestry replaces the ancestry with proxies that will auto-load the ancestry on first access?  If that's so I actually have no objection.  Dat is not being used.  What I had misunderstood from the earlier messages was that flush cached versions and ancestry destroyed ancestry.  As long as that's not true I'm happy.</div><div><br></div><div>I'm still alarmed that my now 54Mb image ballooned to 1.5Gb until it appears I somehow kicked off a cleanup by touching the ancestry proxies.  But that's a different issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Given your own record advocating for the most insidious and dangerous<br>
types of bugs that silently corrupt data (notably, the deeply flawed<br>
ideas about the Auto-Timezone). I suppose you would prefer something<br>
that simply nil's out the ancestry so that when someone saves it,<br>
they're saving a corrupt package?<br></blockquote><div><br></div><div>I've upset you.  I'm sorry.  The latter is what I had misunderstood the situation to be.  Forgive me; when I'm debugging the VM I find myself at the limit of my capacities and when, in the course of bug fixing, I have to interact with some unfamiliar piece of the system I get frustrated.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That's would be a lot worse than an "unpredictable" delay.<br></blockquote><div><br></div><div>I stand corrected.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Jan 19, 2018 at 5:50 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> On 19 January 2018 at 05:30, Chris Muller <<a href="mailto:ma.chris.m@gmail.com">ma.chris.m@gmail.com</a>> wrote:<br>
>><br>
>> It wasn't clear to me that your bloated image issue was related to<br>
>> MCInfoProxy at all -- you said it showed ByteArray's and Bitmaps as<br>
>> the top, but the Proxy wasn't agitated until you ran the<br>
>> pointer-finder.<br>
>><br>
>> As I mentioned, the intention of the design is to allow purging the MC<br>
>> ancestry to recover that memory for building a smaller, tighter<br>
>> production image, without losing the ability to access it,<br>
>> transparently, if needed.  Because no one would want to accidentally<br>
>> save a version with the ancestry gone (corrupt), right?  This design<br>
>> requires<br>
>> no extra thinking, just a little extra waiting.  Conceptually, that<br>
>> feels like a classic cache, to me.  If there's a glitch in how it<br>
>> interacts with MC that could be improved, we should fix it.  I'm<br>
>> curious what else was on that stack..<br>
><br>
><br>
> I've voiced my criticism of that design before, so I'll just point out that<br>
> it's exactly this unpredictable nature of proxy interactions that makes it<br>
> fragile.<br>
><br>
>> I agree, though, it isn't needed on the UI menu, so we should remove<br>
>> it.  It's something one would normally only call from a<br>
>> deployment/build script.<br>
><br>
><br>
> +1<br>
><br>
> If even Master Eliot is confused, we really should not expose it with one<br>
> tempting click ;)<br>
><br>
> - Bert -<br>
><br>
><br>
>><br>
>><br>
>> Best,<br>
>>   Chris<br>
>><br>
>> On Thu, Jan 18, 2018 at 9:43 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>> > Hi Chris,<br>
>> ><br>
>> > On Thu, Jan 18, 2018 at 7:20 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> 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>
>> ><br>
>> ><br>
>> > Can you explain?  How does this create the issue?  Why have an item like<br>
>> > "flush cached versions and ancestry" if its dangerous.  The implication<br>
>> > of<br>
>> > :cached" is that the information can be rebuilt when required.  The<br>
>> > ancestry<br>
>> > is out there in the .mcz files.  I don't understand what's going on<br>
>> > here.<br>
>> > feels like a bad design decision.<br>
>> ><br>
>> >><br>
>> >><br>
>> >>  - Chris<br>
>> >><br>
>> >> On Thu, Jan 18, 2018 at 5:24 PM, Eliot Miranda<br>
>> >> <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Hi All,<br>
>> >> ><br>
>> >> >     I've been experiencing image save slowdowns recently and finally<br>
>> >> > my<br>
>> >> > 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<br>
>> >> > top<br>
>> >> > two,<br>
>> >> > so I looked for large Bitmaps.  I found three that fit this<br>
>> >> > criterion:<br>
>> >> ><br>
>> >> ><br>
>> >> >     Bitmap allInstances select: [:bm| bm size >= 1000000 and: [bm ~~<br>
>> >> > Display<br>
>> >> > bits]]<br>
>> >> ><br>
>> >> > I inspected the three and did a chase pointers on one of them.  As I<br>
>> >> > 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<br>
>> >> > appeared<br>
>> >> ><br>
>> >> > I interrupted this and did a very cursory stack examination. Some<br>
>> >> > object<br>
>> >> > had<br>
>> >> > not understood isLiteral and from there what looked like an attempt<br>
>> >> > to<br>
>> >> > turn<br>
>> >> > this stub into a real object caused FlexibleVocabularies-who.NN to<br>
>> >> > start<br>
>> >> > to<br>
>> >> > download.<br>
>> >> ><br>
>> >> > I threw away the debugger, ran the GC and suddenly all my free space<br>
>> >> > 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.<br>
>> >> > Can<br>
>> >> > we<br>
>> >> > please discuss this?  This doesn't seem like healthy behaviour at all<br>
>> >> > :-)<br>
>> >> ><br>
>> >> > _,,,^..^,,,_<br>
>> >> > best, Eliot<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > _,,,^..^,,,_<br>
>> > best, Eliot<br>
>><br>
><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>