Re: [Valgrind-developers] VALGRIND_MALLOCLIKE/FREELIKE thoughts

[Julian S. <js...@ac...>]

> It seems to me that if we allow heap chunks to be nested, it would give
> us a lot of extra power.  I think it would subsume the mempool
> functionality in a more general way, and allow us to define sub-chunk of
> memory for all sorts of purposes.
>
> The semantics would be:
>
>    1. A new heap chunk  is either not enclosed by another chunk, or is
>       completely contained by an outer chunk.
>           * It follows that if a chunk has sub-chunks, they're
>             completely contained.
>    2. If you free a chunk, it and all its subchunks are freed.
>
> 1 means that chunks are always properly nested.  2 defines the lifespan
> of a chunk (never longer than its containing chunks).

What happens if you try to create a chunk which straddles the boundary
of some other chunk?


> I'm not precisely sure what the semantics of leak-checking would be in
> the presence of nested chunks.  It would depend on how they're being used:
>
>    1. If you have a memory pool, where all memory in the pool is freed
>       together, then the nested chunks should be scanned and marked if
>       the outer chunks are.
>    2. If you have an allocator which is carving a superblock into
>       independent allocations, then scanning and marking should avoid
>       sub-chunks; sub-chunks need to be explicitly referenced to be
>       found not leaked.

I'm loathe to allow more complexity like this into the code base without
a clear customer-needs-this case.  Although it's an interesting idea,
I am very concerned with spiralling complexity and the resulting 
maintenance burden it gives.  At some point we must stop adding
functionality and instead concentrate on stabilising and making
portable what we already have.  And that point is now.

If anything is to happen to functionality, I'd prefer to prune 
away little-used features to make V easier to maintain.

J