Croquet 2 Play

If the size of your .image file has gotten very large without you having saved much work, it is probably due to lingering circular or global references to objects. These objects are referred to as zombies and can enter a zombie state for a host of reasons, but I’ll cover that on my Squeak blog later and link back to here. For now, let’s just deal with how to get rid of them. The first thing to do is to open a Workspace and evaluate:

CroquetHarness cleanup

Next save the image and see if the file size shrunk back to a reasonable level. If not you’ll either have to go zombie hunting or start from a clean image. Sometimes zombie hunting doesn’t produce the results you want. It may be that you’re not looking for the right kind of objects but in other cases, there are just too many zombies of different types and it’s taking a long time to figure out how to untangle them. In either case, if you don’t have any data or graphics bound only to the image, AND your code is reasonably well organized(this doesn’t have to mean Monticello - some projects can be managed well with change sets) the quickest solution may be to just dump the code and load it into a clean image. However, one often learns valuable lessons while zombie hunting so there’s good reason to learn some basic techniques.

The first steps in zombie hunting are simple “is-it-plugged-in” type of things. First look to see if any error windows are hidden from view. Then a look at workspaces you have open in the image and see if you dumped any large objects into variables while exploring. As above, save the image and then check the file size.

Next, you’ll want to identify likely candidate classes that may have instances hanging around. There are no hard and fast rules for this but I tend to look for:

• objects that open and/or initialize central or frequently used UI elements
• objects whose existence depend upon plugins
• objects making calls to any low level system
• objects created by recently loaded packages code I didn’t write

If you browse the CroquetHarness cleanup method, you’ll see a series of statements many of which look like:

SomeClass allInstances do:[:i | i doSomethingToGetRidOfMe.]

I usually get a count first:

SomeClass allInstances size

If there are a lot and you happen to know the appropriate doSomethingToGetRidOfMe method you’re in luck. Things aren’t always that simple though because you may not want to get rid of all the instances or the doSomethingToGetRidOfMe method only works under certain conditions. In the latter case you’ll need some method or script to identify suspect instances

(SomeClass allInstances select: [:z | z suspect]) do:[:i | i doSomethingToGetRidOfMe.]

Often, none of the above works because the doSomethingToGetRidOfMe was not intended to deal with a broad spectrum of circumstances but rather the ones likely to occur under “normal” use. In such cases, one needs more powerful instruments which fortunately Squeak is full of. So start out by opening an ObjectExplorer on all the instances.

 

Then you can use the menu to find out what objects are still referring to each instance and thus preventing it from being garbage collected:

 

This will open an inspector with a list of objects:

that are referencing the instance. If you’re fortunate, there’s an obvious reason why the reference still exists and a convenient doSomethingToGetRidOfMe to clean things up. However, there’s a good chance that neither exist in which case, you’ll need to call upon an experienced zombie buster or become one yourself!

HTH