ProtoObject>>become: is two-way in Pharo.
"...Swap the object pointers of the receiver and the argument.
    All variables in the entire system that used to point to the
    receiver now point to the argument, and vice-versa."

In the unlikely event that I have understood correctly,
Array>>elementsForwardIdentityTo:
is Pharo's one-way become.

On Wed, 1 Apr 2020 at 22:43, jtuc...@objektfabrik.de
<jtuc...@objektfabrik.de> wrote:
>
> 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 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> 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> 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
>
>
>
> --
> Russ Whaley
> whaley.r...@gmail.com
> <Class instances tests.pdf>
>
>
> --
> -----------------------------------------------------------------------
> 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
>
>
>
>
> --
> -----------------------------------------------------------------------
> 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
>
>

Reply via email to