From owner-freebsd-chat Fri Aug 7 21:26:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA26571 for freebsd-chat-outgoing; Fri, 7 Aug 1998 21:26:39 -0700 (PDT) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA26566 for ; Fri, 7 Aug 1998 21:26:36 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id WAA05589; Fri, 7 Aug 1998 22:25:36 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <35CBD340.86A928C9@softweyr.com> Date: Fri, 07 Aug 1998 22:25:36 -0600 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) MIME-Version: 1.0 To: Nate Williams CC: Terry Lambert , jdp@polstra.com, chat@FreeBSD.ORG Subject: Re: Heads up on LFS References: <199808071637.KAA19141@mt.sri.com> <199808072218.PAA01251@usr02.primenet.com> <199808072250.QAA22022@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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