Automatic memory management -- no panacea

One of the loudest criticisms I hear about C++ is that it doesn't have garbage collection. In other words, whenever a program allocates memory, some other part of that program has to figure out when to free it.

Of course, that figuring out can often be automated. As an obvious example, every standard-library container class keeps track of its own memory and frees it as needed. Nevertheless, it is hard to resist the belief that automatically freeing memory would make life a lot simpler for C++ programmers.

In thinking about this claim, I remember a meeting I attended many years ago. In this meeting, some software designers were talking about building a telephone switching system in Lisp--a language that has no way of deallocating memory explicitly at all. What I found interesting was how much of the discussion centered around the disadvantages of automatic memory allocation.

One of these disadvantages was peculiar to switching systems, and probably only to systems of that era: The software had to be designed to be able to work around hardware failure, and memory failure in particular. In this system, every data structure had a corresponding audit routine, the purpose of which was to inspect the data structure, detect any internal inconsistencies, and correct those inconsistencies from the remaining data. These engineers viewed the garbage collector as a program that manipulated one more data structure; and they felt that they would have to augment the memory-management system so that it would be robust in the face of memory failures.

This requirement led to a second problem: In order to reengineer the garbage collector in this way, they would need access to its source code and specifications. Moreover, every time those specifications changed, they would have to rewrite their own version to match those specifications.

The third problem was the possibility that allocating memory might trigger a garbage collection, which in turn might cause the switch to stop for a while to do the garbage collection. Such delays were usually acceptable--as they would simply cause a telephone call to take a little longer to connect or disconnect--but sometimes they were unacceptable. To forestall delays where they could not be tolerated, they talked about preallocating list cells and using them as needed.

In other words, these engineers started out by lauding the advantages of garbage collection, and then proceeded to rewrite the automatic memory-management system to make it manage memory manually. They just didn't have the control they needed for their application.

Of course, telephone switching systems are unusual applications, because they have to be reliable even in the face of hardware failures. Surely there is no need to rewrite the memory-management subsystem for ordinary applications, right?

I'll leave you to ponder that. Meanwhile, comments are welcome.

Posted by Andrew Koenig at 11:17 AM  Permalink