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, jtuc...@objektfabrik.de
<mailto:jtuc...@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.r...@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.r...@gmail.com
<mailto:whaley.r...@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.trussard...@gmail.com
<mailto:dario.trussard...@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.r...@gmail.com <mailto:whaley.r...@gmail.com>
--
Russ Whaley
whaley.r...@gmail.com <mailto:whaley.r...@gmail.com>
<Class instances tests.pdf>
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchelmailto:jtuc...@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:jtuc...@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
