Channels ▼

Andrew Koenig

Dr. Dobb's Bloggers

Automatic Memory Management -- No Panacea

February 06, 2008

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.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video