alloca, malloc and friends

ian reid ir at cel.co.uk
Thu Oct 25 19:16:44 AEST 1990


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 <std/disclaimer.h>
UUCP: ir at cel.uucp or ir at 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."



More information about the Comp.unix.questions mailing list