[gclist] Concerns about GC

[Hans Boehm]

Pinku Surana wrote:

"The problem is that GC does not make economical use of a
valuable resource: memory. The initial start-up requirements for most
GC implementations is 8M of memory, though more often 16M. Everytime a
program requires more than 16M, the system gobbles more memory and
never gives it up (I think Emacs returns free buffer space to the OS,
though)."

I have previously admitted that our collector is not designed to handle
small applications very well.  But the above characterisation completely
contradicts all my experience and several other reported measurements.
I routinely run garbage collected applications using our collector in
something like a .5 MB heap, even without compiling the collector in its
small heap configuration.  If you want to run an application with our
collector on a Windows PC, you probably do need a 8 MB RAM (though
I believe I have done so on a 4MB PC with win32s), but very little of
that is taken up by the garbage collected application.


Whether or not process memory is returned to the OS is largely orthogonal
to whether or not the allocator garbage collects.  If anything, a garbage
collector is in a better position to do so.  My personal opinion is
that returning memory is a dubious proposition without explicit programmer
hints, since it is usually expensive to return memory to the OS and then
reclaim it later.  It should be done very cautiously, if at all, either by
malloc, or by a garbage collector.

All of this aside, there are reaasons garbage collectors should use more
memory than systems with explicit storage management, but also reasons they
should use less.  Which one dominates, depends on the application.

Briefly:

more:  A collector needs additional space to avoid collecting all the time.
Incremental collectors need even more, so that they can keep allocating
during a collection.

less:  No extra copying to preserve single reference invariants.  It's
OK to share data structures.  No space to hold reference counts.  No
other bookkeeping data structures for deallocation.  No leaks in the
conventional sense.  (Only the last one applies if the collector is
retrofitted to an existing project.  Thus it's often hard to quantify
these.)

As has previously been pointed out, you can build infinitely growing data
structures either with or without a collector, so that's an orthogonal issue.
And it is the case that some garbage collectors use too much memory.
So do some other libraries.


Hans
(boehm@mti.sgi.com)
Hans-Juergen Boehm
boehm@mti.sgi.com