Messages in this thread |  | | Date | Tue, 28 Jan 1997 13:50:36 -0500 | From | Jim Richey <> | Subject | Re: Memory use: returning freed memory to the pool |
| |
I have noticed this behavoir in serveral different UNIX's and also the Stratus VOS operating system. I have been told that this is a feature not a bug. When a process mallocs memory and then free's it, the heap space that was allocated to the process continues to be allocated to the process. If the process mallocs the same size, or smaller space, the previously freed space will be reused. If the malloc is for a larger size than what was previously freed and if there is enough memory available after the previously freed area that will allow contiguous memory to be allocated then the previous space is used, plus whatever else is required after that area in order to meet the size requested by the malloc call. However, if contiguous memory cannot be obtained by using the previouly freed space, then an entire new area of memory is allocated. But, the previously freed area is still not returned to the OS until the process terminates. On some systems, if the kernel has to grow the heap space beyond it's initial boundary, this memory remains allocated for heap even after the process terminates, which can be a problem if another process runs later and needs that memory for something else like stack. For a process that does a lot of dynamic allocation of area that is approximately the same size, not returning the memory to the OS certainly increases performance, but if you run other processes that need that memory it can be bad. We run an EDI translator that never terminates. If a large EDI transaction gets translated a large amount of memory gets allocated to the translator process which never gets released for use by other processes. So far the only solution has been to throw money at it by purchasing more memory. I have noticed some System V Rel III based Unix's that do seem to give the memory back to the OS when the process issues a free.
Adam D. Bradley wrote: > > > I may be a bit slow witted, but there is something I don't > > understand about memory management: why doesn't the size of my > > process decrease when I free allocated memory ? > > > > To explain, I've included the program below: this allocates 10 Megs > > (roughly), writes to this memory, to make sure it is actually > > there, then frees it, and goes to sleep for 24 hours. > > > > When I run this, and monitor the process size using top, I see that > > the size of the process stays at 10 Megs: the freed memory is not > > returned to the operating system. > [snip] > > This is, methinks, a libc problem...malloc() will (when necessary) aquire > a heap of memory w/ a system call, then allocate segments within that > heap; free() marks those sections of the heap "de-allocated", but does not > return it to the OS until the program exits. > > There are potential performance hits if free() automatically does a > "hard-release" (correct me if I'm wrong), particularly for > string-intensive and similar applications that are constantly allocating > and freeing substantial amounts of memory. > > > - Is there anyway, in which I can force my process to return the > > memory to the operating system, in such a way that Linux can > > recycle this memory ? ( I only need it when starting my process, > > after init I can throw it out). > > mallopt() provides a mechanism for "tuning" the behavior of the malloc > function set...of course, my DU4.0 man pages say "it's no longer supported > by us, don't use it", and I can't hit any Linux man pages from here :-P > > Adam > -- > He feeds on ashes; a deluded mind has led him Adam Bradley, UNCA Senior > astray, and he cannot deliver himself or say, Computer Science > "Is there not a lie in my right hand?" Isaiah 44:20 > bradley@cs.unca.edu http://www.cs.unca.edu/~bradley <><
-- Jim Richey jrichey@pabs.com HighMark Inc. http://www.highmark.com
|  |