Tim, okay, so I understand the reason. Thanks for clarifying/confirming? I don't think VAST has two-way become. IIRC, VW has. At least I can tell you using nil instead of String new has worked for me on VAST versions ever since 3.0 in the early nineties. What about Pharo? Does it do one-way or two-way become? Joachim Am 01.04.20 um 10:29 schrieb Tim Mackinnon:
Yeah, I was taught (and it may be out of date), that as become: is a 2 way operation the identity of nil (as a singleton) would get swizzled, so it was safer to create a simple new object that could be easily gcâd (thatâs what I vaguely recall anyway). (This was in early VA from the OTI guys, but maybe that gets handled better in modern VA, as I think become: is two way in VA right?)
Tim
On 1 Apr 2020, at 08:11, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote:
Tim,
out of curiosity: why do you suggest to create hundreds of thousands of Strings instead of become: nil?
Does Pharo do two-way become: ? I'be been nilling instances for a little over 2 decades in VAST so far and never had any troubles with it...
Other than that: the become: nil (or String new as you suggest) thing was the first that came to my mind for the intermediate solution as well. Of course that doesn't fix the code which doesn't dispose of the objects in the UI or model...
Joachim
Am 01.04.20 um 08:42 schrieb Tim Mackinnon:
Hi Russ - a quick look at your stats seems to indicate that something is holding on to your model, I didnât understand the first object growing by 2, but the second increases by 1 each time, and it looks like some form of root object holding on  to the others ? This of course means the GC canât reclaim the chain of objects if something is holding on to that root globally.
Assigning something in the playground will hold onto it (I believe) so you can continue to reuse and inspect it - so thatâs expected, but this looks like something in your UI?
You can break the chain manually (but itâs not a full solution), simply iterate over your root and become: String new (Save your image before doing it and see if it works to free up the cycles). Eg try something like this (havenât tried this in Pharo myself, but worked in VA, so it should work here)
MyRootModel allInstances do: [ :m | m become: String new ]
If this works and reduces your memory usage, you now need to inspect one of those MyRootModel instances and see who is referencing it, and explain why. This is Svenâs pointerTo explanation.
For roots, you sometimes can use a WeakDictionary so that when nothing is referencing them, they get gcâd if you are doing some caching or have some factory concept.
Itâs not uncommon to hit this when you get your system nearing completion , itâs the downside of not having to worry about memory referencing - ultimately you have to worry about it at the edges.
It is possible there is a Pharo bug, as over time I see large Pharo images but I was just messing around and put it down to failed experiments.
Hope this helps.
Tim
On 31 Mar 2020, at 20:47, Russ Whaley <whaley.russ@gmail.com> wrote:
 Here is some additional data - attached - I checked the number of instances on select Classes before a UI load, during the UI load and after the UI load (and again). The class instances grow as expected, but do no release. I'm doing something wrong. I'm going to try a fresh image next, however, I expect the same thing to happen, just starting over at zero.
On Tue, Mar 31, 2020 at 12:57 PM Russ Whaley <whaley.russ@gmail.com <mailto:whaley.russ@gmail.com>> wrote:
Dario, Thanks for the reply!
When I closed my image - after running that huge query and leaving it in an inspector... my image grew to 1.3GB, lol.
When I closed the inspector, and all the class browsers, did the garbage collection, etc., it dropped back to 384MB. Still huge, and all my Class instances are still there. I'm getting ready to also drop my Playground - after I copy all the code snippets out and see if that has any impact. I'm also going to try a fresh image and see if there is the same growth pattern as here.
Perhaps I'm doing something wrong with the way I'm creating and storing my object instances - which is generally Class new, fill out some attributes, then add it to a collection or Dictionary.
All my Object tests create sample data (objects) - over and over as well.
On Tue, Mar 31, 2020 at 12:20 PM dario.trussardi65 <dario.trussardi65@gmail.com <mailto:dario.trussardi65@gmail.com>> wrote:
Ciao,
> My image size keeps growing and growing. I've been scouring Google and mailing lists, trying to find a solution.
    i have the same problem with a Pharo 7 image.
    Maybe it has nothing to do.
    But after close all the class browser windows the image save return to a " valid " size.
    Dario
-- Russ Whaley whaley.russ@gmail.com <mailto:whaley.russ@gmail.com>
-- Russ Whaley whaley.russ@gmail.com <mailto:whaley.russ@gmail.com> <Class instances tests.pdf>
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchelmailto:jtuchel@objektfabrik.de Fliederweg 1http://www.objektfabrik.de D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1