Date: Wed, 14 Jul 1999 11:55:03 -0600 From: lyndon@orthanc.ab.ca To: freebsd-hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907141755.LAA05231@orthanc.ab.ca> In-Reply-To: Your message of "Tue, 13 Jul 1999 14:09:56 PDT." <199907132109.OAA80706@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907141755.LAA05231>