RePost: Object deletion problem

[Donn Cave]

Quoth Nick Belshaw <nickb at earth.ox.ac.uk>:
| If someone could spare a moment to explain this little observation -
| I do not know whether it is significant/expected/unexpected....
|
| I am trying to track down a memory leak and noticed the following in a
| piece of test code whilst trying to reproduce some effects.
| On a Linux RedHat6.1 Box if I run the  code and hit the offered build
| button - I simply populate the screen with a number of windows. If I
| then hit the destroy button, the windows are removed and the __del__
| method of each child is called ok, but if I look at memory usage using
| 'Top' I see that no memory is released?
| However - if I increase the dummy-data count  from  30000 to 40000 or
| above, the memory IS released.
|
| Is this ok or might it be giving me a problem?

On UNIX (and other operating systems), the memory allocation procedures
that are used by normal applications are a layer on top of the system
functions (malloc() vs. brk()).  Storage for Python objects is allocated
and released at the malloc level, while the process memory as seen by
top is allocated by brk() (or whatever your platform's C library does.)

Classically, this brk memory is never released at all, it stays at its
high water mark until process exit.  In other words, malloc may call
brk, but free doesn't.  Process memory doesn't need to shrink, really,
because if the high end memory blocks are no longer in use they'll be
paged out as required anyway.  That paging is unnecessary and consumes
resources, though, so maybe your C library is actually shrinking the
process memory when a large region at the high end is free.

My explanation may be wrong on some of the technical details, since
I don't have extensive knowledge of memory allocation internals in
current UNIX platforms, but the key point is that process memory doesn't
directly reflect each malloc & free.

	Donn Cave, donn at u.washington.edu