[gclist] Concerns about GC

[Richard A. O'Keefe]

Pinku Surana says
	Nevertheless, I am still of the opinion that GC should be used
	in a select number of application domains. Furthermore, any language
	that *requires* GC in the runtime system (either explicitly or
	implicitly) dooms the language to a small group of users.

		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).

This simply isn't true.  I have used Lisp and Prolog (GC languages) on a
1Mb Mac plus with no trouble.  The statistics package I use will run in
384k of memory on a Mac, though it would prefer 2Mb (not 8, TWO).  Gambit
runs happily enough in 2Mb.  MacParlog runs in 1M.  Clean is a rather
large system:  a pure lazy functional language which manages to produce
_extremely_ efficient code; perhaps it is because of the large compiler
that it requires 3M.  CAML Light, on the other hand, will run in 500k,
and prefers 1M.  Quintus Prolog ran happily in under 1Mb.

For comparison, Think C says it will run in 1M but prefers 4M (and this is
an _old_ copy of Think C).  For further comparison, the static checker for
C, lclint, absolutely requires 1.4M on a SPARC before it starts, and you
should see what the memory usage goes up to.  The programmer's editor I
use on a Mac (not Emacs, and not using Lisp as its extension language)
requires 2Mb minimum.

In short, there is *NO* necessary connection between "implements GC"
and "requires a lot of memory".

		Though the speed of a program is an important measure of
	program performance, the space requirements are also important.

Right.  That's _why_ GC is so important:  the GC will reclaim storage
even when the programmer dares not.

	These trade-offs are made all the time for real
	programs, but GC immediately chooses speed over space.

This is not true.  Many GC implementations give the programmer control
over the point in the time/space curve.

	Furthermore, though one class
	of problems disappear (memory leaks) another is created: garbage that
	is trapped by badly written programs.

How does this make GC worse than not GC-ing?  If you _don't_ GC, even *more*
garbage will accumulate.

		Rather than depend on GC to solve this class of bugs, more
	support should be provided for programming with explicit memory
	allocation. Annotations, language support, and better programming
	environments are all small steps towards reducing these kind of
	bugs. IMHO, C is too thorny a language to do these things with,

Wrong again.  The LC-lint static checker does exactly that.

		I have found GC to be a blessing for rapid prototyping and
	incremental development environments. But for real systems
	programming, memory is yet another resource that must be used
	sparingly.

Where is it written that systems programming is the only kind of
programming that matters?  On which mountain was it handed down that
the only way to use memory sparingly is to control it manually?
(Hint:  deforestation is not a technique used in C compilers!)

(There was a really fascinating paper on memory use profiling in a recent
conference.  I hope we will see that kind of tool in more GC-capable
programming toolkits.)

	That's what makes programming hard and keeps good
	programmers employed. 

Good programmers try to keep up with the relevant literature and keep
an open mind.