|
From: <sv...@va...> - 2013-09-20 21:34:52
|
Author: florian
Date: Fri Sep 20 21:34:40 2013
New Revision: 13575
Log:
In an attempt to fix the accounting for dynamic memory allocation
it turned out that coregrind freely allocates memory on the tool
arena (which it should not, conceptually) and tools rely on coregrind
doing so (by VG_(free)'ing memory allocated by coregrind).
Entangling this mess is risky and provides little benefit except
architectural cleanliness.
Thinking more about it... It isn't really all that interesting how
much memory is allocated by tool code in and by itself. What is
interesting is the total memory impact a tool has, e.g. as compared
to running "none".
So in this patch the number of memory arenas is consolidated by
subsuming VG_AR_TOOL/ERRORS/EXECCTXT into VG_AR_CORE.
VG_(malloc) and friends have been modified to operate on VG_AR_CORE.
Modified:
trunk/coregrind/m_clientstate.c
trunk/coregrind/m_errormgr.c
trunk/coregrind/m_execontext.c
trunk/coregrind/m_mallocfree.c
trunk/coregrind/pub_core_mallocfree.h
Modified: trunk/coregrind/m_clientstate.c
==============================================================================
--- trunk/coregrind/m_clientstate.c (original)
+++ trunk/coregrind/m_clientstate.c Fri Sep 20 21:34:40 2013
@@ -69,7 +69,7 @@
Int VG_(cl_auxv_fd) = -1;
// Command line pieces, after they have been extracted from argv in
-// m_main.main(). The payload vectors are allocated in VG_AR_TOOL
+// m_main.main(). The payload vectors are allocated in VG_AR_CORE
// (the default arena). They are never freed.
/* Args for the client. */
Modified: trunk/coregrind/m_errormgr.c
==============================================================================
--- trunk/coregrind/m_errormgr.c (original)
+++ trunk/coregrind/m_errormgr.c Fri Sep 20 21:34:40 2013
@@ -791,7 +791,7 @@
*/
/* copy main part */
- p = VG_(arena_malloc)(VG_AR_ERRORS, "errormgr.mre.1", sizeof(Error));
+ p = VG_(malloc)("errormgr.mre.1", sizeof(Error));
*p = err;
/* update 'extra' */
Modified: trunk/coregrind/m_execontext.c
==============================================================================
--- trunk/coregrind/m_execontext.c (original)
+++ trunk/coregrind/m_execontext.c Fri Sep 20 21:34:40 2013
@@ -139,8 +139,8 @@
ec_htab_size_idx = 0;
ec_htab_size = ec_primes[ec_htab_size_idx];
- ec_htab = VG_(arena_malloc)(VG_AR_EXECTXT, "execontext.iEs1",
- sizeof(ExeContext*) * ec_htab_size);
+ ec_htab = VG_(malloc)("execontext.iEs1",
+ sizeof(ExeContext*) * ec_htab_size);
for (i = 0; i < ec_htab_size; i++)
ec_htab[i] = NULL;
@@ -289,8 +289,8 @@
return; /* out of primes - can't resize further */
new_size = ec_primes[ec_htab_size_idx + 1];
- new_ec_htab = VG_(arena_malloc)(VG_AR_EXECTXT, "execontext.reh1",
- sizeof(ExeContext*) * new_size);
+ new_ec_htab = VG_(malloc)("execontext.reh1",
+ sizeof(ExeContext*) * new_size);
VG_(debugLog)(
1, "execontext",
@@ -312,7 +312,7 @@
}
}
- VG_(arena_free)(VG_AR_EXECTXT, ec_htab);
+ VG_(free)(ec_htab);
ec_htab = new_ec_htab;
ec_htab_size = new_size;
ec_htab_size_idx++;
@@ -420,10 +420,9 @@
/* Bummer. We have to allocate a new context record. */
ec_totstored++;
- new_ec = VG_(arena_perm_malloc)( VG_AR_EXECTXT,
- sizeof(struct _ExeContext)
- + n_ips * sizeof(Addr),
- vg_alignof(struct _ExeContext));
+ new_ec = VG_(perm_malloc)( sizeof(struct _ExeContext)
+ + n_ips * sizeof(Addr),
+ vg_alignof(struct _ExeContext));
for (i = 0; i < n_ips; i++)
new_ec->ips[i] = ips[i];
Modified: trunk/coregrind/m_mallocfree.c
==============================================================================
--- trunk/coregrind/m_mallocfree.c (original)
+++ trunk/coregrind/m_mallocfree.c Fri Sep 20 21:34:40 2013
@@ -684,17 +684,11 @@
// Initialise the non-client arenas
// Similarly to client arena, big allocations will be unsplittable.
arena_init ( VG_AR_CORE, "core", CORE_REDZONE_DEFAULT_SZB,
- 1048576, 1048576+1 );
- arena_init ( VG_AR_TOOL, "tool", CORE_REDZONE_DEFAULT_SZB,
4194304, 4194304+1 );
arena_init ( VG_AR_DINFO, "dinfo", CORE_REDZONE_DEFAULT_SZB,
1048576, 1048576+1 );
arena_init ( VG_AR_DEMANGLE, "demangle", CORE_REDZONE_DEFAULT_SZB,
65536, 65536+1 );
- arena_init ( VG_AR_EXECTXT, "exectxt", CORE_REDZONE_DEFAULT_SZB,
- 1048576, 1048576+1 );
- arena_init ( VG_AR_ERRORS, "errors", CORE_REDZONE_DEFAULT_SZB,
- 65536, 65536+1 );
arena_init ( VG_AR_TTAUX, "ttaux", CORE_REDZONE_DEFAULT_SZB,
65536, 65536+1 );
nonclient_inited = True;
@@ -2307,27 +2301,27 @@
void* VG_(malloc) ( const HChar* cc, SizeT nbytes )
{
- return VG_(arena_malloc) ( VG_AR_TOOL, cc, nbytes );
+ return VG_(arena_malloc) ( VG_AR_CORE, cc, nbytes );
}
void VG_(free) ( void* ptr )
{
- VG_(arena_free) ( VG_AR_TOOL, ptr );
+ VG_(arena_free) ( VG_AR_CORE, ptr );
}
void* VG_(calloc) ( const HChar* cc, SizeT nmemb, SizeT bytes_per_memb )
{
- return VG_(arena_calloc) ( VG_AR_TOOL, cc, nmemb, bytes_per_memb );
+ return VG_(arena_calloc) ( VG_AR_CORE, cc, nmemb, bytes_per_memb );
}
void* VG_(realloc) ( const HChar* cc, void* ptr, SizeT size )
{
- return VG_(arena_realloc) ( VG_AR_TOOL, cc, ptr, size );
+ return VG_(arena_realloc) ( VG_AR_CORE, cc, ptr, size );
}
HChar* VG_(strdup) ( const HChar* cc, const HChar* s )
{
- return VG_(arena_strdup) ( VG_AR_TOOL, cc, s );
+ return VG_(arena_strdup) ( VG_AR_CORE, cc, s );
}
// Useful for querying user blocks.
@@ -2338,7 +2332,7 @@
void* VG_(perm_malloc) ( SizeT size, Int align )
{
- return VG_(arena_perm_malloc) ( VG_AR_TOOL, size, align );
+ return VG_(arena_perm_malloc) ( VG_AR_CORE, size, align );
}
Modified: trunk/coregrind/pub_core_mallocfree.h
==============================================================================
--- trunk/coregrind/pub_core_mallocfree.h (original)
+++ trunk/coregrind/pub_core_mallocfree.h Fri Sep 20 21:34:40 2013
@@ -40,14 +40,11 @@
/* Allocation arenas.
- CORE for the core's general use.
- TOOL for the tool to use (and the only one it uses).
+ CORE for the core's and tools' general use.
DINFO for debug info (symbols, line #s, CFI, etc) storage.
CLIENT for the client's mallocs/frees, if the tool replaces glibc's
malloc() et al -- redzone size is chosen by the tool.
DEMANGLE for the C++ demangler.
- EXECTXT for storing ExeContexts.
- ERRORS for storing CoreErrors.
TTAUX for storing TT/TC auxiliary structures (address range
equivalence classes).
@@ -55,16 +52,13 @@
*/
typedef Int ArenaId;
-#define VG_N_ARENAS 8
+#define VG_N_ARENAS 5
#define VG_AR_CORE 0
-#define VG_AR_TOOL 1
-#define VG_AR_DINFO 2
-#define VG_AR_CLIENT 3
-#define VG_AR_DEMANGLE 4
-#define VG_AR_EXECTXT 5
-#define VG_AR_ERRORS 6
-#define VG_AR_TTAUX 7
+#define VG_AR_DINFO 1
+#define VG_AR_CLIENT 2
+#define VG_AR_DEMANGLE 3
+#define VG_AR_TTAUX 4
// This is both the minimum payload size of a malloc'd block, and its
// minimum alignment. Must be a power of 2 greater than 4, and should be
|
|
From: Philippe W. <phi...@sk...> - 2013-09-21 19:51:56
|
On Fri, 2013-09-20 at 21:34 +0000, sv...@va... wrote: > Author: florian > Date: Fri Sep 20 21:34:40 2013 > New Revision: 13575 > > Log: > In an attempt to fix the accounting for dynamic memory allocation > it turned out that coregrind freely allocates memory on the tool > arena (which it should not, conceptually) and tools rely on coregrind > doing so (by VG_(free)'ing memory allocated by coregrind). > Entangling this mess is risky and provides little benefit except > architectural cleanliness. > Thinking more about it... It isn't really all that interesting how > much memory is allocated by tool code in and by itself. What is > interesting is the total memory impact a tool has, e.g. as compared > to running "none". > So in this patch the number of memory arenas is consolidated by > subsuming VG_AR_TOOL/ERRORS/EXECCTXT into VG_AR_CORE. > VG_(malloc) and friends have been modified to operate on VG_AR_CORE. I think the main objective of the arenas is not to support memory reporting (this is better done using --profile-heap=yes) but rather segregate memory allocation. I do not know of an explicit explanation of why we have these arenas (e.g. for exectxt) but I suspect the idea is to have e.g. "permanently kept pieces of memory once allocated" (e.g. exectxt or errors) to be separated from memory which is (supposed to be) more often allocated then freed. I guess this is to help decreasing fragmentation of the heap. Now, I am not very sure if these arenas really have a positive effect. I once did a trial to have only 2 arenas: * the client arena * the rest (i.e. all of core + tool) On big test, IRC, this was giving 8% less memory. Not very clear to me what to do with these arenas. |