|
From: Bart V. A. <bar...@gm...> - 2008-04-05 15:54:50
|
Hello,
Is anyone relying on the current behavior of VG_(malloc)(), namely
that it initializes all memory it allocates with the pattern 0xdd ?
I'd like to disable this behavior, either conditionally or
unconditionally.
Bart.
Index: coregrind/m_mallocfree.c
===================================================================
--- coregrind/m_mallocfree.c (revision 7844)
+++ coregrind/m_mallocfree.c (working copy)
@@ -1270,6 +1270,7 @@
a->bytes_on_loan -= b_pszB;
+#if 0
/* If this is one of V's areas, fill it up with junk to enhance the
chances of catching any later reads of it. Note, 0xDD is
carefully chosen junk :-), in that: (1) 0xDDDDDDDD is an invalid
@@ -1278,6 +1279,7 @@
Vbits representation for memcheck. */
if (aid != VG_AR_CLIENT)
VG_(memset)(ptr, 0xDD, (SizeT)b_pszB);
+#endif
// Put this chunk back on a list somewhere.
b_listno = pszB_to_listNo(b_pszB);
|
|
From: Julian S. <js...@ac...> - 2008-04-05 16:45:37
|
> Is anyone relying on the current behavior of VG_(malloc)(), namely > that it initializes all memory it allocates with the pattern 0xdd ? I prefer to keep it as it is, since it tends to enhance debuggability of the system. Why do you want to disable it? J |
|
From: Bart V. A. <bar...@gm...> - 2008-04-05 17:56:41
|
On Sat, Apr 5, 2008 at 6:40 PM, Julian Seward <js...@ac...> wrote: > > > Is anyone relying on the current behavior of VG_(malloc)(), namely > > that it initializes all memory it allocates with the pattern 0xdd ? > > I prefer to keep it as it is, since it tends to enhance debuggability > of the system. Why do you want to disable it? Because of performance reasons. When e.g. allocating memory for bitmaps, such memory is first allocated with VG_(malloc)(), initialized to 0xdd inside VG_(malloc)(), and then reinitialized to 0x00 by the caller of VG_(malloc)(). This is a waste of CPU cycles. Possible solutions are: * Provide two memory allocation functions, one that initializes the allocated memory to 0xdd and one that does not initialize the allocated memory. * Implement a global variable that allows enabling / disabling the initialization of memory to 0xdd. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2008-04-05 18:47:38
|
On Sat, Apr 5, 2008 at 7:56 PM, Bart Van Assche <bar...@gm...> wrote: > > On Sat, Apr 5, 2008 at 6:40 PM, Julian Seward <js...@ac...> wrote: > > > > > Is anyone relying on the current behavior of VG_(malloc)(), namely > > > that it initializes all memory it allocates with the pattern 0xdd ? > > > > I prefer to keep it as it is, since it tends to enhance debuggability > > of the system. Why do you want to disable it? > > Because of performance reasons. When e.g. allocating memory for > bitmaps, such memory is first allocated with VG_(malloc)(), > initialized to 0xdd inside VG_(malloc)(), and then reinitialized to > 0x00 by the caller of VG_(malloc)(). This is a waste of CPU cycles. > Possible solutions are: > * Provide two memory allocation functions, one that initializes the > allocated memory to 0xdd and one that does not initialize the > allocated memory. > * Implement a global variable that allows enabling / disabling the > initialization of memory to 0xdd. Probably I'm too much used to glibc. Maybe I should just call VG_(calloc)() instead ? Bart. |
|
From: Julian S. <js...@ac...> - 2008-04-05 20:27:54
|
> Because of performance reasons. When e.g. allocating memory for > bitmaps, such memory is first allocated with VG_(malloc)(), > initialized to 0xdd inside VG_(malloc)(), and then reinitialized to > 0x00 by the caller of VG_(malloc)(). This is a waste of CPU cycles. This is true. (Except the 0xDD fill is done at deallocation time, not allocation time). But the question is, can you reliably, repeatably, measure any performance loss? I suspect you'd have to deallocate at the rate of several tens of megabytes per second to see much difference, in which case 1. at least for small deallocations, the overhead of the allocator itself is much larger (it generates many cache misses) 2. if you really need to allocate/deallocate that fast, it might be a sign that some higher-level algorithmic fix might be more effective VG_(memset)'s main loop is vectorised and unrolled in an attempt to minimise the cost. Really it depends on the actual performance numbers. J |
|
From: Bart V. A. <bar...@gm...> - 2008-04-06 11:30:34
|
On Sat, Apr 5, 2008 at 10:23 PM, Julian Seward <js...@ac...> wrote: > > > Because of performance reasons. When e.g. allocating memory for > > bitmaps, such memory is first allocated with VG_(malloc)(), > > initialized to 0xdd inside VG_(malloc)(), and then reinitialized to > > 0x00 by the caller of VG_(malloc)(). This is a waste of CPU cycles. > > This is true. (Except the 0xDD fill is done at deallocation time, > not allocation time). > > But the question is, can you reliably, repeatably, measure any > performance loss? I suspect you'd have to deallocate at the rate > of several tens of megabytes per second to see much difference, in > which case > > 1. at least for small deallocations, the overhead of the allocator > itself is much larger (it generates many cache misses) > > 2. if you really need to allocate/deallocate that fast, it might > be a sign that some higher-level algorithmic fix might be more > effective > > VG_(memset)'s main loop is vectorised and unrolled in an attempt > to minimise the cost. > > Really it depends on the actual performance numbers. Some numbers (obtained by tracing an exp-drd run of Firefox with callgrind): * VG_(malloc)() took up about 2% of the time for this run. * VG_(free)() took up about 11% of the time for this run. * 82% of the execution time of VG_(free)() was spent in VG_(memset)(). Based on these numbers I expect that the effect of commenting out the VG_(memset)() call will be measurable. Note: I'm still working on decreasing the number of VG_(malloc)() / VG_(free)() calls in exp-drd. Bart. |