<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 14, 2017 at 1:23 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
<br>
>> On Mar 13, 2017, at 1:27 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>><br>
>> Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> writes:<br>
>>> stash the metadata for each allocation (and pointers for corresponding<br>
>>> free) in a hash table for all mallocs that we need to track? [this<br>
>>> avoids the wasted 'space' in each alloc.]<br>
>><br>
>> Sure, but this is just duplicating an implementation of malloc.<br>
><br>
>    No it isn't. It is a very thin wrapper around multiple current mallocs.<br>
<br>
</div></div>Meh, the proposal has more storage overhead than malloc().<br></blockquote><div><br></div><div>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. =)<br><br></div><div>--Richard <br></div></div><br></div></div>