|
From: Nicholas N. <nj...@cs...> - 2005-03-01 00:24:52
|
On Mon, 28 Feb 2005, Jeremy Fitzhardinge wrote: >> If anything is to happen to functionality, I'd prefer to prune >> away little-used features to make V easier to maintain. >> > Yeah, I'd agree with that (ie: VALGRIND_MAKE_*). > > The MALLOCLIKE/FREELIKE stuff clearly serves a need for anyone who has > their own allocator (Valgrind, for example), but I'm guessing they > haven't been used much. The mempool changes are presumably useful, > otherwise Robert wouldn't have bothered with them. I'm looking to > condense the normal heap stuff and the mempool stuff into a single > unified mechanism, and make that mechanism actually work in a useful way. > > But I'm not planning on doing anything beyond bug-fixing for now (which > I consider the MAKE_* issue to be). I'd be happy for VALGRIND_MAKE_* to not create its own blocks, I don't think we'd lose much with that. In fact, I vaguely recall that the memory address identification code has to do some awkward things to deal with those special blocks. As for MALLOCLIKE/FREELIKE, they're good enough for simple custom allocators. See memcheck/tests/custom_alloc.c for an example. I'm not surprised that they causes problems if you use it with malloc(); that's not something I'd considered, because I didn't think anyone would build a custom allocator on top of malloc(). There may certainly be room for improvement. N |