Path: utzoo!attcan!uunet!mnemosyne.cs.du.edu!mercury.cair.du.edu!diana.cair.du.edu!rwelch From: rwelch@diana.cair.du.edu (RANDY S WELCH) Newsgroups: comp.unix.questions Subject: Re: alloca, malloc and friends Message-ID: <1990Oct26.052528.3922@mercury.cair.du.edu> Date: 26 Oct 90 05:25:28 GMT References: <6793@suns302.cel.co.uk> Sender: news@mercury.cair.du.edu (netnews) Organization: University of Denver Lines: 32 In-Reply-To: ir@cel.co.uk's message of 25 Oct 90 09:16:44 GMT In article <6793@suns302.cel.co.uk> ir@cel.co.uk (ian reid) writes: The problem is that there is no way that this memory can be returned to the operating system, at least no way documented on the sbrk(2) manual page which is where I would expect to find it, after all free(3) is documented on the malloc page. free simply returns the memory to the pool managed by malloc not to the operating system, the documented behaviour. Well imagine this, an application mallocs (insert a number here which is a large amount of memory for system), this is a one-off occurrence and this much memory is never needed again. But the application size can never shrink, therefore a lot of memory which is not being used is unavailable to the system. Ian Reid #include UUCP: ir@cel.uucp or ir@cel.co.uk or ...!{ukc,mcsun,uunet}!cel!ir "Computers..proof positive that no-one yet understands how to describe any real world situation in 0's and 1's." You might want take a look at the malloc that is on prep.ai.mit.edu. It is capable of returning memory back to the system. And it does seem to work. I am currently using as the malloc when compiling GNU Emacs. And it seems to work rather well. Worth looking at. -randy -- Randy Welch Mail to : ...!ncar!scicom!bldr!randy or rwelch@du.edu Boulder, CO VOICE : 303-442-6717 "Unfortunately, life contains an unavoidable element of unpredictability" -David Lynch "The Angriest Dog in the World"