|
From: <sv...@va...> - 2012-02-08 22:28:31
|
Author: philippe
Date: 2012-02-08 22:23:55 +0000 (Wed, 08 Feb 2012)
New Revision: 12369
Log:
mc_main.c statistics has hard-coded logic to compute
the memory used by sec vbit table. This logic depends
on the way sec Vbit entries are maintained.
Due to the introduction of pool alloc, this logic has
to be changed to (more) correctly compute the memory.
Verified on f12/x86 by comparing the memory reported
by the memcheck stats with what is given by --profile-heap=yes.
Modified:
trunk/memcheck/mc_main.c
Modified: trunk/memcheck/mc_main.c
===================================================================
--- trunk/memcheck/mc_main.c 2012-02-04 17:16:40 UTC (rev 12368)
+++ trunk/memcheck/mc_main.c 2012-02-08 22:23:55 UTC (rev 12369)
@@ -6122,10 +6122,13 @@
// Three DSMs, plus the non-DSM ones
max_SMs_szB = (3 + max_non_DSM_SMs) * sizeof(SecMap);
// The 3*sizeof(Word) bytes is the AVL node metadata size.
- // The 4*sizeof(Word) bytes is the malloc metadata size.
- // Hardwiring these sizes in sucks, but I don't see how else to do it.
+ // The VG_ROUNDUP is because the OSet pool allocator will/must align
+ // the elements on pointer size.
+ // Note that the pool allocator has some additional small overhead
+ // which is not counted in the below.
+ // Hardwiring this logic sucks, but I don't see how else to do it.
max_secVBit_szB = max_secVBit_nodes *
- (sizeof(SecVBitNode) + 3*sizeof(Word) + 4*sizeof(Word));
+ (3*sizeof(Word) + VG_ROUNDUP(sizeof(SecVBitNode), sizeof(void*)));
max_shmem_szB = sizeof(primary_map) + max_SMs_szB + max_secVBit_szB;
VG_(message)(Vg_DebugMsg,
|