Hi Russ - > On 1 Apr 2020, at 17:14, Russ Whaley <whaley.r...@gmail.com> wrote: > > A couple of basic questions... > I thought tempVariables, inside a method were automatically destroyed when > the method terminated? > If I pass an object (either a parm or tempVariable) that resides in that > message to another message, since I'm passing the actual object - I curious > how it ever gets GC'd. > All my ObjectTest classes create their own data to work with - I have the > creation in centralized messages, but they return 'fresh' data for each test. > Whatever the answer is in the first 2 bullet points, this could be a > contributor to the volume.
For the first 1, its not so much the “temp” ness of variables, but more about how the object they point to gets referenced. Normally in a method, you assign an object to a variable, you use it, nothing else references it, and it just gets GC’d. However if you call a setter: of another object, and pass in your temp variable as an argument, that other object now has a reference to it. Now if that other object is referenced in a class variable (or some other global), the gc will consider it referenced and won’t eliminate it. Basically every object reference gets traversed to see if its pinned in some way. Those objects that are not pinned (i.e. held onto anymore) get collected. There are numerous algorithms to do this efficiently, and you can read up on them (the basic one is mark and sweep). I recall that a global variable is anything that can be traced back to the Smalltalk system dictionary (which is the root of the world). There might be some other known roots (this is my vague memory on this. The above should answer your question #2 (if not, I’m sure we can find the relevant docs on this, its quite well explained somewhere). For #3, it shouldn’t be the volume of data created - its what is holding on to this data - do you cache it somehow (and end up referencing it in a global variable so it can’t be gc’d) - OR - if its just UI related (this might be a good test, if you create your model without a UI, and print something on the transcript, does memory still grow?). If its UI related - this could be some Spec handler that reaches back into the global system dictionary to process events (or something like this), and this is what is pinning your model. Or is there some phantom window that is tied to OS resources which stop it from properly terminating (but might not be visible). This is the kind of thing you need to look for. Spec2 is quite new, so it could be something there that is causing this. If you suspect its UI related, maybe you can create a really simple example with a simpler model subset that can recreate it. Hope this helps guide you on next steps. Tim
