28 April, 2005

From Memory Management to Garbage Collection

In the bad old days of primitive object oriented programming, all was empty and waste, and darkness covered the face of software development. The programmer was responsible for managing memory. This overburdened the poor programmer with the arduous task of freeing objects' memory when they were no longer needed (unless they were on the stack). Memory leaks could occur; careless and incompetent programmers might forget to free unneeded objects, tying up memory for no productive purpose. (This is also called upgrading.)

Then there was light. In order to free the long-suffering programmer from the terrible responsibility of understanding object life-lines, Sun and Microsoft have blessed us with Java and Java++ (aka C#/.NET), respectively. These are OO (object obsessed) languages, wherein everything must be a class member, so classes such as Math exist solely to contain static methods. (Classes as object templates is such an old-fashioned concept.) Being more familiar with .NET, I will attempt to expound upon the wonders of the latter.

Memory in .NET is managed by a Garbage Collector, which completely absolves the developer from tracking memory usage and knowing when to free memory. Nirvana! No longer do we have to concern ourselves with memory management. Instead of one destructor, we now have three:
Dispose
Finalize
Ensuring that no pointers are pointing to it.

Before releasing a .NET object, you must call Dispose, if it has such a method. This is needed because the object may have to deal with unmanaged resources such as database connections and file handles. Then you can set all its pointers to null, and wait for the Garbage Collector to free its memory. Before doing this, the GC will call Finalize (implemented as a destructor in C#), so that the object can deal with unmanaged resources, such as database connections and file handles. Finalizers slow down the garbage collection, so it is recommended that this is actually done in Dispose. An important consideration is the mid-life crises. If an object is not disposed and nulled as soon as it is finished with, the garbage collector is liable to get out of whack.

So, to summarize: You must call Dispose on a .NET Object as soon as you have finished with it, then set its reference to null. This is so much better the old way of simply deleting/freeing, particularly as you have the added excitement of non-determinate finalization.

When designing a class, things get far more exciting though. Since there may be many references to an object, Dispose must be callable multiple times. It should also call GC.SuppressFinalization(this) for performance reasons. You have more leeway with Finalize; it is protected and should only be invoked by the GC (although somebody playing with reflection can invoke anything they want). You may therefore assume that it will only be called once, and only when there are no live pointers to it. Beware of weak references though. Another problem with finalize is that is not guaranteed to be called at any particular time, so you cannot rely on it to free resources (unmanaged or otherwise) in a timely manner.

If you find any of this confusing, Microsoft have helpfully provided a simple example of all this in action. Luckily, their simple example doesn't actually do anything; if it did, they would have had to consider a huge, steaming pile of horrendous complexities.

Now you understand how Microsoft have eradicated memory leaks. They have made resource management so complicated that incompetent and careless programmers will give up before they start. Competent and careful developers will spend all their time learning how to do it properly, and never get around to writing actual code.

18 April, 2005

Etymology of Politics

'tis the season for political parties to throw mud and spread deceit here in the UK, so I take this apt opportunity to enlighten you as to the source of the word "politic". "Poli" is from the Latin poly, meaning many, and "tic" is from tick, a blood-sucking parasite.

06 April, 2005

Refuting Evolution

Creationists claim that contemporary biodiversity is too complex to have evolved through random mutation. Evolutionists respond by pointing out that, if enough monkeys were randomly pounding away on enough typewriters for enough time, they would eventually produce the works of Shakespeare.

Well, thanks to the Internet, the creationists have been vindicated. The complete works of Shakespeare have yet to appear on any blog.