lkml.org 
[lkml]   [1997]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Memory allocation errors
Date
From
In message <m0vpIfb-0005FcC@lightning.swansea.linux.org.uk>,Alan Cox writes:
> > >From info received here, I decided to make my own check of a possible
> > memory allocation bug. I can confirm that the bug does, indeed, exist.
>
> libc malloc does not return memory to the kernel instead it uses a local
> pool. Thats standard for almost all Unix libc malloc implementations as
> very few applications have the property you describe and the malloc heap
> tends to have freed holes in it not a single giant free chunk.

Indeed.
In general, it would be a very *bad* idea to have free move the break back.
System calls are not free, and the normal pattern of events for memory
allocation is such that space freed is likely to soon be reused or that
the process exits freeing all its resources. The usual implementation
means that most long running processes reach a "steady state" where they
don't have to move the break at all (unless they have one or more memory
leaks :-)

If you are in the situation of writing a program which you know requires
large memory allocations initially, but should *really* free them up
subsequently, you should create the code to do this (e.g. use mmap).

t

--
Tim Wright, Worldwide Technical Services, | Email: timw@sequent.com
Sequent Computer Systems Inc., 15450, |
SW Koll Parkway, Beaverton, Oregon 97006 | Phone: +1-503-578-3822
"Applying computer technology is simply finding the right wrench to pound
in the correct screw"



\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.048 / U:0.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site