Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Basic heap usage statistics in GCC on 64-bit platform

I need to answer a basic question from inside my C program compiled by GCC for Linux: how much of process heap is currently in use (allocated by malloc) and how much resides if free heap blocks. GNU implementation of standard library has mallinfo function which reports exactly what I need, but it only usable with 32-bit configurations and, AFAIK, there's no 64-bit equivalent of that functionality (BTW, anyone knows why?).

I use GCC on Linux, so I need this for Linux. But I assume that the heap is opaque to the system, so the only way to answer this question is to use the means provided by the implementation of the standard library.

In MSVC implementation on Windows platform there's no equivalent of mallinfo function but there's so called heap-walk functionality, which allows one to calculate the necessary information by iterating through all blocks in the heap. AFAIK, there's no heap-walk interface in GNU C library. (Is there?).

So, again, what do I do in GCC? It doesn't have to be efficient, meaning that the aforementioned heap-walk based approach would work perfectly fine for me. How do I find out how much heap is in use and how much is free in GCC? I can probably try installing malloc-hooks and "manually" track the sizes, although I'm not sure how to determine the current heap arena size (see mallinfo.arena) without using mallinfo.

like image 692
AnT Avatar asked May 09 '10 16:05

AnT


1 Answers

This thread from 2004 involving key glibc developers indicates that since the interface already "...does not fit the implementation at all.", there was seen as little point in making a 64-bit clean version of it. (The mallinfo() interface wasn't designed for glibc - it was being considered for inclusion in the SUS).

Depending on what you're trying to do with the information, you might be able to use malloc_stats(), which just produces output on standard error - since it's just textual output it's able to change to match the internal implementation of malloc(), and will therefore at least have the advantage of producing sensible results.

like image 161
caf Avatar answered Sep 21 '22 14:09

caf