[gclist] Concerns about GC

[Pinku Surana]

	I am quite familiar with languages implemented with GC behind
the scenes. My main development language is LISP and I've used Boehm's
collector for some projects written in C. I've used various other
systems and languages with a myriad of different implementations of
GC (Smalltalk, ML, Scheme, etc).

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

	Though the speed of a program is an important measure of
program performance, the space requirements are also important. For
example, there are plenty of data structures that are fast for certain
applications, but are infeasible because of the space
requirements. These trade-offs are made all the time for real
programs, but GC immediately chooses speed over space.

	GC'ers claim, correctly, that this technology makes the
construction of large systems easier, all those nasty memory leaks
disappear. However, this savings for engineers comes at a cost to the
end user by eating more of his memory. Furthermore, though one class
of problems disappear (memory leaks) another is created: garbage that
is trapped by badly written programs. Of course, the program still
runs, but over time it consumes more and more space and the computer
grows sluggish. 

	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, but a
semantically clean C-like language designed with support for memory
allocation in mind would be a step in the right direction. 

	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. That's what makes programming hard and keeps good
programmers employed. 

Just my 2 cents.

Pinku Surana