|
From: Philippe W. <phi...@sk...> - 2016-10-06 19:58:39
|
I am a little bit lost in the documentation and/or semantic of the recently added meta mempool feature. First, valgrind.h tells: ... When the VALGRIND_MEMPOOL_AUTO_FREE is passed, a MEMPOOL_DELETE will auto-free all chunks (so not reported as leaks) for allocators that assume that destroying a pool destroys all objects in the pool. ... But this operation MEMPOOL_DELETE does not exist. This looks to be rather VALGRIND_MEMPOOL_FREE. In the manual, the description is somewhat different. Second thing confusing me: The user manual tells for META mempool first describe the auto free flag: ... This indicates that items allocated from this memory pool are automatically freed when VALGRIND_MEMPOOL_FREE is used on a block. ... But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the addr given as argument is supposed to be a chunk of the pool, and is released. So, this flag is by itself useless, unless it is combined with VALGRIND_MEMPOOL_METAPOOL. Do I miss something ? Assuming I did not miss something, then we now have a new macro VALGRIND_CREATE_META_MEMPOOL(pool, rzB, is_zeroed, flags) which in its names indicates it is a meta pool. So, it is unclear why we ask the user to specify VALGRIND_MEMPOOL_METAPOOL and/or allows the user to specify VALGRIND_MEMPOOL_AUTO_FREE, as this will be useless unless the pool is a real meta pool. (checking the code, effectively, the only thing an AUTO_FREE pool does is to release automatically the '2nd level smaller blocks' when a 'first level pool bigger block' is released with VALGRIND_MEMPOOL_FREE The second flag documented is also somewhat confusingly described: ... This indicates that memory that has been marked as being allocated with VALGRIND_MALLOCLIKE_BLOCK is used by a custom allocator to pass out memory to an application (again marked with VALGRIND_MALLOCLIKE_BLOCK). ... I do not see anything in tests and/or code that would implement something like a double level of VALGRIND_MALLOCLIKE_BLOCK. As I understand, we have a first level of blocks which are described with VALGRIND_MEMPOOL_ALLOC Then, such first level blocks can be split and allocated using VALGRIND_MALLOCLIKE_BLOCK. I think it would be better to clarify the documentation and maybe remove this (useless for the user) VALGRIND_MEMPOOL_METAPOOL : The underlying (internal) client request might effectively be the same (and so have an 'internal' flag VALGRIND_MEMPOOL_METAPOOL but it looks to me that describing this flag to the user is just confusing. Philippe |