From owner-freebsd-hackers Wed Jul 14 10:56:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 1554015146 for ; Wed, 14 Jul 1999 10:56:31 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id LAA05231 for ; Wed, 14 Jul 1999 11:55:04 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907141755.LAA05231@orthanc.ab.ca> To: freebsd-hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 14:09:56 PDT." <199907132109.OAA80706@apollo.backplane.com> Date: Wed, 14 Jul 1999 11:55:03 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I mean, jeeze, the reservation for the program stack alone would eat > up all your available swap space! What is a reasonable stack size? The > system defaults to 8MB. Do we rewrite every program to specify its own > stack size? How do we account for architectural differences? The alternative is to rewrite every program that assumes the semantics of malloc() are being followed. The problem I have as an applications writer is that I tend to believe malloc. To pick a specific example, our IMAP client takes steps to ensure it won't run out of memory in critical sections. We maintain a "rainy day" pool block of memory. If we receive a NULL from malloc, we 1) free up whatever memory we can in other parts of the client (possibly using the rainy day pool to stage data out to disk), and 2) if necessary, reduce the size of the rainy day pool. This whole design is predicated on malloc() telling the truth. If instead it gives us a bogus block of memory, then seg faults when we try to use it, the best we can do is try to shut down without losing any of the users mail (and in fact we don't even do that, since there are just too many places where this can happen in third-party libraries that we aren't willing to rewrite). Sending us a kill signal is even worse. (And extremely unfair, since we take pains to not waste memory in the first place.) Has anyone analyzed all those applications people talk about that show huge allocation footprints but don't actually use the memory? That represents the code that needs to be fixed. Breaking malloc() is not a suitable response IMO. As a data point, we routinely disable overcommit on our SGI machines and it doesn't hurt us one bit. And we aren't allocating gigabytes of swap space, either. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message