Re: [Valgrind-developers] A new performance problem in arena_malloc

[Christoph B. <bar...@gm...>]

Am Freitag 13 Juli 2007 schrieb Julian Seward:
> > Each arena has a set of N_MALLOC_LISTS circular double-linked lists of
> > free blocks, classified by size (see  pszB_to_listNo).   I think each
> > list arbitrarily travels across all the Superblocks in the Arena.
> > The arena's freelist[] array contains pointers to some arbitrary entry
> > point in each list.
>
> (more)
>
> The mapping from block sizes to list numbers, and the number of lists,
> is entirely arbitrary.  The only requirement is that all block sizes get
> mapped to one of the lists.  The current scheme tends to work fairly
> well but maybe you can find something better.


Is it possible to give memory back to the system that is allocated in the 
arena manager?

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?

BTW, what is the difference between the client and valgrind versions of this 
functions? I do not get this from the header.

Currently all arenas have a redzone of at least 4 bytes? Is this neccessary? 
Or is this a protection for faults in valgrind itself?

Christoph