Date: Fri, 07 Aug 1998 22:25:36 -0600 From: Wes Peters <wes@softweyr.com> To: Nate Williams <nate@mt.sri.com> Cc: Terry Lambert <tlambert@primenet.com>, jdp@polstra.com, chat@FreeBSD.ORG Subject: Re: Heads up on LFS Message-ID: <35CBD340.86A928C9@softweyr.com> References: <199808071637.KAA19141@mt.sri.com> <199808072218.PAA01251@usr02.primenet.com> <199808072250.QAA22022@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the course of Nate and Terry ranting back and forth about memory allocators
and garbage collectors, Nate Williams wrote:
> *Right* And you've never written a program that leaked memory, nor had
> *any* errors due to malloc/free problems, or dealt with them.
>
> If you can say that every program you ever written that used dynamic
> memory has never had problems, then I don't believe you. Because there
> are problems, a GC scheme can (and oftentimes) does a better job because
> it keeps track of things for you. Studies have shown this to be true.
I have written *several* programs, systems really, that don't leak memory.
We prove this by running them at 95+% usage for 30 days at a time and
monitor the memory usage. Since these are embedded systems, if they leak,
they eventually crash. It is *not* true that every C or C++ program
leaks memory, as each of these systems was implemented in C and/or C++
(running on VxWorks).
The only way to guarantee your system doesn't leak is by inspecting every
memory allocation and ascertaining that it has a balancing release, via
every possible exit out of the code. This is time-consuming and mind
boggling work. A distant second is to instrument your memory allocator
and run the hell out of the system, while monitoring the memory usage.
Nate makes a very valid point, that most C/C++, and even UNIX programmers
seem to miss. We're willing to use software to optimize our programs,
compile them from high-level languages to machine code, and in some cases,
even generate the program source from pictures we draw, but not to use
software to make memory allocation easier, or less error-prone? This
is truly silly.
I suggest all of those arguing the evils of garbage collectors go read the
excellent series of columns written by P.J. Plaugher on this exact topic
in Embedded System Programming earlier this year. Regardless of your
"embeddedness" this is an excellent education in why garbage collectors
are here to stay, and why they will become more common in future systems.
Please note that P.J. wrote this series of columns as he was designing and
developing a garbage collection system for embedded C++ programs; he wasn't
just "winging it."
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes@softweyr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35CBD340.86A928C9>