Re: Memory use: returning freed memory to the pool

Jim Richey (jrichey@pabs.com)
Tue, 28 Jan 1997 13:50:36 -0500

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