|
From: Nicholas N. <nj...@cs...> - 2007-07-14 13:26:30
|
On Sat, 14 Jul 2007, Christoph Bartoschek wrote: > Is it possible to give memory back to the system that is allocated in the > arena manager? I don't think so. > Currently all allocations are done using am_sbrk_anon_float_valgrind or > am_sbrk_anon_float_client. For the later one could use > am_mmap_anon_float_client and release memory with am_munmap_client. But > there is no am_munmap_valgrind that releases memory from > am_mmap_anon_float_valgrind. Is there a reason for this? I think it's not uncommon for heap allocators to not return memory, but I could be wrong. > BTW, what is the difference between the client and valgrind versions of this > functions? I do not get this from the header. Do you mean VG_(malloc) vs. VG_(arena_malloc), for example? The former just calls VG_(arena_malloc) with the arena set to VG_AR_TOOL. See coregrind/m_mallocfree.c. > Currently all arenas have a redzone of at least 4 bytes? Is this neccessary? > Or is this a protection for faults in valgrind itself? See the comment "Layout of an in-use block" in coregrind/m_mallocfree.c. The redzones covers space needed for bookkeeping purposes anyway. Well, for blocks larger than 16 bytes it could probably be avoided, but it does provide some safety against overruns in Valgrind itself as you suggest. Nick |