Am Sonntag, 25. November 2007 schrieb Christoph Bartoschek:
> I wonder how to reduce the memory overhead of valgrind. Currently I see the
> following numbers:
> Total allocated memory by valgrind: 130 GiB
> Memory overhead of aspace manager: 15 GiB
> Memory mmap'd by the arenas: 111 GiB
> Memory mmap'd by the client arena: 59 GiB
> Memory given to the client: 38 GiB
> Malloc overhead + Wasted Mem: 21 GiB
> Memory mmap'd by the tool arena: 52 GiB
> Memory given to the tool: 41 GiB
> Malloc overhead + Wasted Mem: 11 GiB
> Wasted memory my missing munmap: 3 GiB
I think the memory overhead of aspace manager is in real the shadow memory. I
missed that no arena is used for it.
Currently my run takes 188 GiB with the following distribution:
core : 458752 mmap'd, 26432/ 26362 max/curr
tool : 98739159088 mmap'd, 80585380882/ 65440290042 max/curr
symtab : 9246176 mmap'd, 8938189/ 8743762 max/curr
client : 80113007878 mmap'd, 50036789540/ 43109716719 max/curr
demangle: 0 mmap'd, 0/ 0 max/curr
exectxt : 721032 mmap'd, 565912/ 565912 max/curr
errors : 65536 mmap'd, 584/ 576 max/curr
ttaux : 524288 mmap'd, 47268/ 46972 max/curr
The client takes the biggest part of memory. However it allocates only two
Size: 40 Live blocks: 545464570
Size: 64 Live blocks: 799360540
The allocated chunks with size 40 are the MC_Chunk elements. They have size 32
and occupy 40 bytes with the malloc overhead.
The chunks with size 64 are the SecVBitNode elements if I identify them
correctly. They are 32 byte big but there are 24 bytes overhead from OSetNode
and 8 bytes from malloc.
Now I wonder whether it is necessary to have the elements in a sorted set. I
do not see where their ordering is used.
By using a malloc without overhead for the MC_Chunk elements one would get 4
GiB back. Using the same for SecVBitNode would save 6 GiB.
If I am correct one could use a hash table for the SecVBitNode. This would
reduce the overhead by about 8 bytes per element. Additionally maybe the
garbage collection is no longer necessary because of the average O(1) runtime
of the hash operations. This would save additional 8 bytes.
Altogher this might save 22 GiB out of 188 GiB.
Any comments on this?