On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes: > > >> On Mar 13, 2017, at 1:27 PM, Jed Brown <[email protected]> wrote: > >> > >> Satish Balay <[email protected]> writes: > >>> stash the metadata for each allocation (and pointers for corresponding > >>> free) in a hash table for all mallocs that we need to track? [this > >>> avoids the wasted 'space' in each alloc.] > >> > >> Sure, but this is just duplicating an implementation of malloc. > > > > No it isn't. It is a very thin wrapper around multiple current > mallocs. > > Meh, the proposal has more storage overhead than malloc(). > I was bored or something, so I actually looked into how people who want to track all the allocations inside a special malloc() do so, and it seems that plenty of people use a red-black tree for this (balanced binary tree, O(log(n) for search, insert/delete, and tree rearrangement) rather than a hash table. This is getting pretty far down in the weeds... but this would have less storage overhead than a hash table. Just FYI. =) --Richard
