System-API to get current process memory usage for C/C++ p..

Matt · External Since: Oct 31, 2004 Posts: 3

What if any system calls exist to get the current process' system
memory usage (including all of the current process' threads) in a
C/C++ based program?

I'm trying to write unit tests to make sure that my memory allocation
processes (for Boost "smart pointers") are actually deallocating
correctly after thousands of dynamic allocations...and my presumption
is that a current-process-memory-usage "self check" will be very
useful for my self-running unit test.

I'd prefer cross-platform calls (be it POSIX, unix/linux, Boost C++,
etc) if I can get them, but I'll take a system specific all (for my
testing prototype) if I must.

Thanks for any help,
-Matt
--
Remove the "downwithspammers-" text to email me.

Ian Collins · External Since: Feb 16, 2006 Posts: 21

Matt wrote:
> What if any system calls exist to get the current process' system
> memory usage (including all of the current process' threads) in a
> C/C++ based program?
>
> I'm trying to write unit tests to make sure that my memory allocation
> processes (for Boost "smart pointers") are actually deallocating
> correctly after thousands of dynamic allocations...and my presumption
> is that a current-process-memory-usage "self check" will be very
> useful for my self-running unit test.
>
> I'd prefer cross-platform calls (be it POSIX, unix/linux, Boost C++,
> etc) if I can get them, but I'll take a system specific all (for my
> testing prototype) if I must.
>
> Thanks for any help,
> -Matt
> --
> Remove the "downwithspammers-" text to email me.

I do this with my own operators new() and delete(). This assumes that
you don't use malloc in your C++.

If you use Solaris, the dbx debugger can do this for you on exit.

--
Ian Collins.

Gordon Burditt · External Since: Mar 16, 2006 Posts: 1

>What if any system calls exist to get the current process' system
>memory usage (including all of the current process' threads) in a
>C/C++ based program?

It's difficult to use this number for anything meaningful. In
particular, free() is unlikely to reduce it, since free()d memory
is usually (depending on the system) made available for reallocation
by this process itself, not given back to the OS.

>I'm trying to write unit tests to make sure that my memory allocation
>processes (for Boost "smart pointers") are actually deallocating
>correctly after thousands of dynamic allocations...and my presumption
>is that a current-process-memory-usage "self check" will be very
>useful for my self-running unit test.

A debugging version of malloc/free that tracks memory usage
would be much more helpful than something that tries to track *ALL*
memory usage.

>I'd prefer cross-platform calls (be it POSIX, unix/linux, Boost C++,
>etc) if I can get them, but I'll take a system specific all (for my
>testing prototype) if I must.

On some systems, you could get an approximation of this number from
sbrk(0). It's almost completely useless for tracking whether you forgot
to free() something. The part that isn't useless involves putting
whatever code in a loop and testing if the value continues to go up
indefinitely.

Gordon L. Burditt

David Schwartz · External Since: Jun 05, 2004 Posts: 813

"Gordon Burditt" <gordonb.75sek DeleteThis @burditt.org> wrote in message
news:121hofa5b1erv65@corp.supernews.com...

> It's difficult to use this number for anything meaningful. In
> particular, free() is unlikely to reduce it, since free()d memory
> is usually (depending on the system) made available for reallocation
> by this process itself, not given back to the OS.

Note that this is *virtual* memory he is talking about here, not
physical memory.

DS

Gordon Burditt · External Since: Mar 16, 2006 Posts: 1

>> It's difficult to use this number for anything meaningful. In
>> particular, free() is unlikely to reduce it, since free()d memory
>> is usually (depending on the system) made available for reallocation
>> by this process itself, not given back to the OS.
>
> Note that this is *virtual* memory he is talking about here, not
>physical memory.

And so am I. free() is unlikely to give back memory, physical or
virtual, to the OS.

Some of the reasons include (1) parts of the page may still be in
use, (2) an OS that uses sbrk() can only return the last memory
allocated, (3) mmap() aligns stuff by pages and the only really
practical way to be able to release memory is to use one mmap() per
request, but it wastes so much memory for small (e.g. less than 4
pages worth) requests it's not practical, and (4) hanging on to the
memory in the process for later re-use is considered an optimization
which is usually effective but can be pathological in corner cases.

Gordon L. Burditt