Path: utzoo!attcan!uunet!mcsun!ukc!stl!cel!ir From: ir@cel.co.uk (ian reid) Newsgroups: comp.unix.questions Subject: alloca, malloc and friends Keywords: alloca, malloc Message-ID: <6793@suns302.cel.co.uk> Date: 25 Oct 90 09:16:44 GMT Organization: Crosfield Ltd., Hemel Hempstead, United Kingdom. Lines: 39 Hi, Just seeking a bit of historical perspective here on alloca and malloc. Forgive me if this has already been discussed, but occassionaly we suffer breaks in news at this site, usually after I have posted an article or question :-(. There seems to me to be a fundamental flaw in the implementation of malloc, as I can determine the implementation from TFM. As I understand it malloc(3) manages an area of memory in the data segment, if there is insufficient space in the data segment a call to sbrk(2) is made to increase the size of the data segment, and hence the memory available for malloc to manage. The size of the application therefore grows by the amount of memory added to the data segment. 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. I'm specualting that alloca(3) which allocates memory on the stack frame was invented for two reasons. Firstly to overcome the above flaw in malloc, and secondly for speed. alloca has it's own flaws though, it's operating system, compiler and architecture dependant (I think this means it's not portable:-)) , and as if this weren't enough there is no documented way to grow the stack segment so there's less chance of being able to get the memory you want. Is this a fair summary. email, flames welcome. -- 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."