out of curiosity: why do you suggest to
create hundreds of thousands of Strings instead of become: nil?
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...
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
���
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.
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.
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
--
--
<Class instances tests.pdf>