[gclist] Concerns about GC

[Greg Hudson]

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

Suppose I have a program which uses explicit memory management.  It
allocates some big object, passes around a bunch of pointers to that
object, and then frees it, leaving some dangling pointers to that
object hanging around.  Say that, for complicated semantic reasons, it
never uses any of those dangling pointers (maybe it's a global
variable that's only used during the initialization stage).  We have a
perfectly correct (if badly written) program which doesn't leak any
memory.  But if we instead used garbage collection and didn't
explicitly free the object, we would have a program with a memory
leak.

This kind of problem is probably less common than traditional memory
leaks, but if your language supports automatic destruction when a
variable goes out of scope (e.g. C++), then traditional memory leaks
don't have to be very common either.

All of which is not to say that I agree with Pinku, who is probably
making the canonical mistake of confusing "garbage collection" with
"emacs," but I've always valued garbage collection more for its
contribution to language safety and interface design than for its
purported ability to prevent memory leaks.