Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!tank!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: Eiffel vs. C++ (vs Smalltalk)
Message-ID: <77300031@p.cs.uiuc.edu>
Date: 15 Jun 89 15:05:00 GMT
References: <5316@tekgvs.LABS.TEK.COM>
Lines: 21
Nf-ID: #R:tekgvs.LABS.TEK.COM:5316:p.cs.uiuc.edu:77300031:000:1120
Nf-From: p.cs.uiuc.edu!johnson    Jun 15 10:05:00 1989


One of the original papers on the Xerox Cedar environment talked about
the importance of garbage collection for long-lived programs.  They
claimed that it was virtually impossible to write a large program that
allocated memory dynamically and NEVER lost a byte.  Perhaps they just
didn't try hard enough.

Anyway, they found that many programs would run for a few months and
then run out of memory.  These programs would go for days at a time
without losing memory, then the part of the program that contained the
space leak would finally get exercized and memory usage would jump up.
Eventually, the program would use up memory.

I don't have much experience with programs like this, but I found
their arguments in favor of garbage collection pretty compelling.

Not having garbage collection has a big effect on your data structures.
Instead of picking the data structure that makes your program the most
efficient and easiest to understand, you pick one that makes memory
management simpler.  Managing memory by hand adds one more constraint
to the design process, and the more it is constrained, the harder it gets.