<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 26, 2013 at 10:47 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Dec 27, 2013 at 12:21 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br><div class="gmail_quote">On Thu, Dec 26, 2013 at 2:29 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div> >> Isn't clang multithreaded? What about synchronization?<br>



</div>  no (afaict)<br>
  If it ever becomes multithreaded, we can guard the push_backs by a mutex (will add a tiny bit of ugliness)</blockquote></div><div class="gmail_extra"><br></div></div>I think we could probably do a lot cheaper than a vector at least for the common case -- we know we will *never* need to traverse this, and it will probably be relatively small (at least, I hope...).<br>


</div><div class="gmail_extra"><br></div><div class="gmail_extra">I would compile some big single source files (single-source gcc, some super big C++ code, etc.) with a hack that prints out how many free() calls are being omitted via this flag. If the number is O(10000) I would probably do something kinda horrible:</div>

</div></blockquote></div><div>I expect it to be more like ~10 than ~10000. Remember we don't need to store all leaked heap objects there, only the roots.</div></blockquote><div><br></div><div>Sure. But run the experiment. I just worry that we may end up with many roots due to some pattern of free calls.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">"""</div><div class="gmail_extra">static const unsigned NumPointersPerGraveYard = ((1 << 16) / sizeof(void*)) - 1;<br></div></div></blockquote>

<div><br></div></div><div>But this is so much more code than a single vector!?</div></blockquote><div><br></div><div>In terms of lines? Yes. But *way* less in terms of actual generated code I would wager. And the whole point of --disable-free was that free() was getting called frequently enough to slow things down. I don't want to add a call to malloc() on that path! ;]</div>
<div><br></div><div>We could use a SmallVector, but that may end up being still more code, and would be much harder to make the loader just zero initialize everything for us....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>(And I like the naming!)</div></blockquote><div><br></div><div>=] </div></div></div></div>