(... I had such a good time with my rant about the .NET CLR yesterday, I thought I'd continue the series...)
This is another in my series of foaming rants whereby you the reader become convinced of my status as a coding dinosaur. So be it.
<rant type=foaming optional=absolutely>
As part of my subscription to Microsoft’s Developer Network (MSDN) I receive monthly issues of MSDN Magazine. You might think this would be a great thing, full of useful information, but really it is just a weird wonder to me. For one thing, most of the technology under discussion in this magazine is only of esoteric interest – things like Avalon (the replacement for GDI in Windows Vista), XAML (the non-procedural language used to define GUIs in Avalon), and Indigo (a new technology for remote object instantiation, supposedly fast enough to be useful, unlike COM+ and DCOM).
The point of view taken by this magazine is that the proper study for a software engineer is to learn how to use Microsoft’s tools to get their work done. Not how to understand user requirements, not how to design systems that work, not how to build code which runs fast and robustly, no, the idea is that if only you understand the tools well enough, they will do all that other stuff for you! Nobody I know believes this to be true – nobody just outside their senior year of college, anyway – but that is the point of view of the magazine. (Which I suspect is edited by people just outside their senior year of college.)
Okay, enough of that, on to today’s subject; which is: memory management! Ta da!
As we all know, memory leaks are one of the crummy things that have plagued programmers since the first core memory at time zero. One of the Really Great Things about managed code is that it completely solves memory leaks! Yes, that’s right, if you write your applications in C# or ASP.NET you will never have to worry about memory management.
So in a recent issue of MSDN Magazine one can find an article entitled “Identify and Prevent Memory Leaks in Managed Code”. How can this be? Memory leaks in managed code?
See, it turns out that there are two kinds of memory leaks. First, there are situations where memory is allocated, never to be freed again (or at least, never until the process is terminated – one of the best arguments for CGI in web applications, but I digress). This is the garden variety memory leak we all know and love. Second, there are situations where memory is allocated, and it will be freed someday, but it hasn’t been freed yet. This is a new exotic type of memory leak we don’t all know and don’t love, and which is the subject of the article in question. The difference is a bit philosophical, because if your program runs out of memory it doesn’t really matter whether there was a bunch of memory just about to be freed or not.
The situation is this. Under the covers, “managed code” means your program is a bunch of hints to a master program about what to do. The master program is called the CLR (Common Language Runtime, which is a misnomer, because it is actually an interpreter, running code in an intermediate language called MIDL (Microsoft Intermediate Language), but I digress). When objects are allocated by your program, the CLR grabs memory from a heap. Your program never needs to deallocate objects explicitly, instead the CLR has a background activity called the Garbage Collector (GC) which figures out which objects are no longer being used, and puts them back on the heap.
In the old world of compiled code, you had to remember which objects you’d allocated, and explicitly free them. This was crummy and led to a lot of garden variety leaks. In the new world of managed code, you don’t have to remember which objects you’ve allocated, and you don’t have to explicitly free them. This is great, no more garden variety leaks! Unfortunately the GC is sitting back there trying to figure out which objects are no longer being used, and when to put them back on the heap. It may have a bunch of objects which it will free someday, but which it isn’t sure it should delete now. These can lead to an exotic type leak. The article in question has a great term for this situation, a “midlife crisis”! There you are, with all this memory which could be freed, but the GC won’t do it, and your program don’t know this is going on, and poof you run out of memory. The solution is that you have to provide hints to the GC so it knows when to free memory, and thereby avoid a midlife crisis.
Okay, let’s summarize. In the old world of compiled code, you had to remember which objects you’d allocated and explicitly free them. This was crummy and led to a lot of garden variety leaks. In the new world of managed code,
If you read this article you will really be impressed by the incredible variety of ways memory can be in limbo under the CLR. The kinds of things you have to do so the GC can figure out what to do are amazing. There is really a lot to learn, the situation is much more complicated than the old days, when you just had to delete everything which was new’ed. Whether this represents progress is a matter for debate, but you know which side I’m on…