extra-heap program memory consumption as showed by valgrind

Question

My program use a lot of memory. This is what valgrind massif tool is showing me:

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 28 38,531,086,036      760,235,208      143,002,822   617,232,386            0

As you can see extra part is few times bigger than useful heap.

What should I do to reduce this extra memory? Do less allocations?

Is this so called memory fragmentation?

OS: Linux 2.6. Program is written in C. It should work 24\7 and it manipulate a lot of data.

Answer 1

Are you allocating lots of extremely small objects -- say, just a couple of bytes? There's a certain amount of overhead associated with every allocation (because, e.g., free needs to be able to tell how big the block was).

This is what's sometimes called "internal fragmentation", as opposed to "external fragmentation" where there's a certain amount of unallocated memory but you can't use it because it's split up into blocks that are too small for you to use. (Another reason why malloc doesn't ever return really small blocks is because this helps reduce external fragmentation.)

If you are allocating lots of very small objects, you should consider managing them separately rather than allocating them individually on the heap. This may well be better in other ways too (e.g., improving memory locality) if you do it right.

Answer 2

According to the documentation, the "extra-heap" bytes are as follows:

The number of extra heap bytes allocated at that point. This reflects the number of bytes allocated in excess of what the program asked for. There are two sources of extra heap bytes.

First, every heap block has administrative bytes associated with it. The exact number of administrative bytes depends on the details of the allocator. By default Massif assumes 8 bytes per block, as can be seen from the example, but this number can be changed via the --heap-admin option.

Second, allocators often round up the number of bytes asked for to a larger number, usually 8 or 16. This is required to ensure that elements within the block are suitably aligned. If N bytes are asked for, Massif rounds N up to the nearest multiple of the value specified by the --alignment option.

This doesn't sound like memory fragmentation to me.

Memory fragmentation is typically caused by lots of small allocations. You end up with small gaps between each unit of allocated memory and then it becomes difficult to get a contiguous region of memory for larger allocations.

To prevent memory allocation basically make less allocations! Use the stack space wherever possible (e.g. don't needlessly use new) and if possible consider pooling frequently allocated objects so that you don't keep allocating memory.

Answer 3

You could either do less allocations of bigger size or tweak the heap - the latter will be implementation-specific.

This is not fragmentation, just when you ask for say 7 bytes the heap allocates not less than 7 bytes - that can be say 16 bytes, so 9 bytes become "extra" and are in fact wasted. This is done for various reasons - for example, to maintain alignment.