This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Memory Leaks in Smalltalk
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
Let me just get off on the wrong foot with everybody. Smalltalk does not have Memory Leaks. It cannot, it will not and you can't make it.
Right, now that that's out of the way, how can you leak memory in Smalltalk? Well, you can call a C program outside of the VM, allocate some memory and then never let it go. That's always a good one. I've fallen for that one several times when plugging in to libraries such as LibXSLT and SDL.
But the more common way to leak memory is not technically a "Memory Leak" in the classical sense. No memory has leaked, you can always recover the memory and there are ways of identifying what the problem is.
In Smalltalk you can accidentally link two objects together in a way you didn't intend that will result in one object holding on to the other. But how? you ask, well, the easiest way is through triggers and dependencies. Say you add a dependency between one of your objects and a class. The class will never get GC'd, because it's in Smalltalk. Thus, the class will hold on to your object forever.
In the case of WithStyle, I've had a memory leak plaguing me for months now. We have a system of Formula that perform a simple mathematic function. A Formula can be an algebraic variable in another Formula. It can also act in common mathematic functions such as *, +, / and -, etc. It's core concept, though, is that it will tell dependent formulas that its value has changed so that they can update their value immediately or later.
With that in mind, once a Formula knows its variables, it adds itself to those variables as dependencies. A variable in our system was always meant to be another Formula. But in my memory leak, it was adding a dependency to an Integer object, not a Formula.
The problem with Integer's is that they're part of the classic Smalltalk-80 class hierarchy. No body has had the balls to go and change the default class hierarchy to be anything more than it already is. That includes adding the ability to handle dependencies or trigger events themselves. Therefore, any thing that is subclassed off Object uses a 3rd party object called DependentsFields to link from them to their dependents.
This DependentsFields dictionary is by neccesity a hard link between the two objects, meaning that no GCing will ever occur on anything that is inside this dictionary. VisualAge has a similiar flaw. In both systems the answer is to subclass off an object that handles its dependencies and trigger interests in a weak collection or similar. But as I mentioned before, classic Smalltalk-80 classes do not use this sort of behaviour.
So, by having a Formula link to an Integer, it was adding itself in to a loop of Non-GC that could not be broken until it were removed from the DependentsFields dictionary. VisualWorks at least provides a nice way to discover this. They have a quick 'Inspect' menu to let you check what's in the DependentsFields dictionary. But it still takes a mental leap to realise you should even look in there.
The end result: All WithStyle tests now check the DependentsFields dictionary to confirm that no WithStyle class instance exists in it. WithStyle now releases all objects as it should. Huge sigh and phew from me I can tell you. Get the latest WithStyle from http://www.softwarewithstyle.com.
Previous Topic
