|
From: Philippe W. <phi...@sk...> - 2016-10-13 19:43:50
|
Thinking more at the interface to create a meta pool:
Either we keep the current name and we ensure (in the macro
expansion) that the meta flag is set
or alternatively, we change the name to be more general
maybe VALGRIND_CREATE_FLAGGED_MEMPOOL
or VALGRIND_CREATE_MEMPOOL_WITH_FLAGS
or VALGRIND_CREATE_GENERAL_MEMPOOL
or (using the linux naming convention when they forgot the flags arg)
VALGRIND_CREATE_MEMPOOL2 (if the digit tells this is macro nr 2)
or VALGRIND_CREATE_MEMPOOL4 (if the digit indicates the nr of args?)
We also indicate that using the AUTO_FREE flag without the
META flag is an error (at least today).
The more general name allows to re-use the same macro for
other kinds of pools (in case we would need new kinds in
the future) just by adding new flags.
Philippe
On Fri, 2016-10-07 at 07:28 +0200, Julian Seward wrote:
> Philippe, thanks for looking at this more. I think this needs to
> be clarified with the original author of the feature, and I am not
> sure he (Ruurd) is on the mailing list. Cc-ing therefore.
>
> For reference, the tracking bug is
> https://bugs.kde.org/show_bug.cgi?id=367995
>
> J
>
> On 06/10/16 21:59, Philippe Waroquiers wrote:
> > 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
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> >
>
|