Messages in this thread |  | | Subject | Re: Memory allocation errors | Date | Tue, 28 Jan 1997 16:06:39 PST | From | Tim Wright <> |
| |
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"
|  |