After object delete, when the heap memory returned to OS?

[wenmang]

Hi,
I am trynig to use unix top untility to monitor the size of a program
whose mainly duty is to call new/delete to store/retrieve some
contents. During the load testing, I notice that the size of the
program increases to a certain point, then stablizes, but I didn't
notice that the size of the program decreases with time. Is top utility
program a good one to monitor potential memory leak? When is OS going
to claim the unused heap memory from still running program(s)?
thanks.

[Victor Bazarov]

we*****@yahoo.com wrote:

I am trynig to use unix top untility to monitor the size of a program
whose mainly duty is to call new/delete to store/retrieve some
contents. During the load testing, I notice that the size of the
program increases to a certain point, then stablizes, but I didn't
notice that the size of the program decreases with time. Is top utility
program a good one to monitor potential memory leak? When is OS going
to claim the unused heap memory from still running program(s)?

Please ask this in the OS newsgroup. The language does not (because it
simply cannot) specify any of OS behaviour.

V

[Mirek Fidler]

we*****@yahoo.com wrote:

Hi,
I am trynig to use unix top untility to monitor the size of a program
whose mainly duty is to call new/delete to store/retrieve some
contents. During the load testing, I notice that the size of the
program increases to a certain point, then stablizes, but I didn't
notice that the size of the program decreases with time. Is top utility
program a good one to monitor potential memory leak? When is OS going
to claim the unused heap memory from still running program(s)?
thanks.

This depends on C++ standard library implementation and OS.

In Unix, the standard behaviour for application (and standard C/C++
library behaviour) is to never return memory once allocated from OS, so
obviously "delete"ed memory will never decreases numbers in top.

OTOH, if under load you total memory consumption after while with
constant load stabilizes, it is a good indicator that your C++ code
reuses deleted memory for "new" allocations, so likely there are no
memory leaks.

Mirek

[Kai-Uwe Bux]

Victor Bazarov wrote:

we*****@yahoo.com wrote:

I am trynig to use unix top untility to monitor the size of a program
whose mainly duty is to call new/delete to store/retrieve some
contents. During the load testing, I notice that the size of the
program increases to a certain point, then stablizes, but I didn't
notice that the size of the program decreases with time. Is top utility
program a good one to monitor potential memory leak? When is OS going
to claim the unused heap memory from still running program(s)?

Please ask this in the OS newsgroup. The language does not (because it
simply cannot) specify any of OS behaviour.

Ha, Catch 22: in that group the OP will be told the the OS does not (because
it simply cannot) specify the semantics of delete in C++ :-)

Unfortunately both answers are correct; and as a result, the standard does
not state any useful postcondition for calls to delete or delete[].
Best

Kai-Uwe Bux

[Victor Bazarov]

Kai-Uwe Bux wrote:

Victor Bazarov wrote:

we*****@yahoo.com wrote:

I am trynig to use unix top untility to monitor the size of a program
whose mainly duty is to call new/delete to store/retrieve some
contents. During the load testing, I notice that the size of the
program increases to a certain point, then stablizes, but I didn't
notice that the size of the program decreases with time. Is top utility
program a good one to monitor potential memory leak? When is OS going
to claim the unused heap memory from still running program(s)?
Please ask this in the OS newsgroup. The language does not (because it
simply cannot) specify any of OS behaviour.

Ha, Catch 22: in that group the OP will be told the the OS does not (because
it simply cannot) specify the semantics of delete in C++ :-)

Then the only sensible choice after that is to ask in a newsgroup for
the compiler. It includes the best (and the worst) of both worlds :-)
[..]

V

[Maxim Yegorushkin]

Mirek Fidler wrote:

[]

This depends on C++ standard library implementation and OS.

In Unix, the standard behaviour for application (and standard C/C++
library behaviour) is to never return memory once allocated from OS, so
obviously "delete"ed memory will never decreases numbers in top.

It might be worth mentioning that this standard behavior for glibc can
be altered using mallopt(M_TRIM_THRESHOLD, ...).

Also, the GNU C++ std::allocator<> adds another layer of memory
caching, which sometimes does more harm then good for multithreaded
appications. See thread
http://groups.google.com/group/comp....7409cb80cbcad0