Garbage Collection in C Programs

LISP and Java programmers take garbage collection for granted. With the Boehm-Demers-Weiser library, you easily can use it in C and C++ projects, too.

The first word that came to mind when I
heard about introducing Garbage Collection techniques into a C or C++
program was “nonsense”. As with any other decent C programmer
who loves this
language, the thought of leaving
the management of my own memory to others seemed nearly offensive. I had a
similar feeling 15 years ago, when I first heard about
compilers that would generate assembly code on my
behalf. I was used to writing my code directly in 6510 opcodes, but that
was Commodore 64—and a totally different story.

What Is Garbage Collection?

Garbage Collection (GC) is a mechanism that provides
automatic memory reclamation for unused memory blocks.
Programmers dynamically allocate memory, but
when a block is no longer needed, they do not
have to return it to the system explicitly with
a free() call. The GC engine takes care of
recognizing that a particular block of allocated
memory (heap) is not used anymore and puts it
back into the free memory area. GC
was introduced by John McCarthy in 1958, as the memory
management mechanism of the LISP language. Since
then, GC algorithms have evolved and now can
compete with explicit memory management. Several
languages are natively based on GC. Java
probably is the most popular one, and others include
LISP, Scheme, Smalltalk, Perl and Python. C and
C++, in the tradition of a respectable, low-level approach to system resources management,
are the most notable exceptions to this list.

Many different approaches to garbage
collection exist, resulting in some families of
algorithms that include reference counting,
mark and sweep and copying GCs. Hybrid
algorithms, as well as generational
and conservative variants, complete the
picture. Choosing a particular GC algorithm
usually is not a programmer's task, as the
memory management system is imposed by the adopted
programming language. An exception to this rule is
the Boehm-Demers-Weiser (BDW) GC library, a
popular package that allows C and C++ programmers
to include automatic memory management into their
programs. The question is: Why would they want to
do a thing like this?

The Boehm-Demers-Weiser GC Library

The BDW library is a freely available library that
provides C and C++ programs with garbage collection capabilities. The
algorithm it employs belongs to the family of mark and sweep
collectors, where GC is split into two phases. First, a scan of all the
live memory is done in order to mark unused blocks. Then, a
sweep phase takes care of putting the marked blocks in the free
blocks list. The two phases can be, and usually are, performed separately to increase the general response time of the library. The BDW
algorithm also is generational; it concentrates free space searches on
newer blocks. This is based on the idea
that older blocks statistically live longer. To put it another way, most
allocated blocks have short lifetimes. Finally, the BDW algorithm
is conservative in that it needs to make assumptions on which
variables are actually pointers to dynamic data and which ones
only look that way. This is a consequence of C and C++ being weakly
typed languages.

The BDW collector comes as a static or dynamic library and is
installed easily by downloading the corresponding package (see Resources) and
running the traditional configure, make and make install commands. Some
Linux distributions also come with an already-made package. For example,
with Gentoo you need to type only emerge boehm-gc to
install it. The
installed files include both a shared object (libgc.o) and a static
library (libgc.a).

Using the library is a fairly straightforward task; for newly developed
programs, you simply call GC_alloc() to get memory and then forget
about it when you do not need it anymore. “Forget about
it”
means setting all the pointers that reference it to NULL. For already
existing sources, substitute all allocation calls
(malloc, calloc, realloc) with the GC-endowed ones. All
free() calls are replaced with nothing at all, but do set any relevant pointers
to NULL.

GC_alloc() actually sets the allocated
memory to zero to minimize the risk that
preexisting values are misinterpreted as valid pointers by the GC
engine. Hence, GC_alloc() behaves more like calloc()
than malloc().

Using GC in Existing C Programs

If you want to try GC in an existing application, manually
editing the source code to change mallocs and frees is not necessary. In
order to redirect those calls to the GC version, you basically have
three options: using a macro, modifying the malloc hooks and overriding
glibc's malloc() with libgc's malloc(). The first approach is the easiest
one;
you simply need to insert something like: