[lkml]   [1997]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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
    > <><

    Jim Richey
    HighMark Inc.

     \ /
      Last update: 2005-03-22 13:38    [W:0.021 / U:5.816 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site