<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 27, 2013 at 11:39 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">
<div class="im">On Fri, Dec 27, 2013 at 2:10 AM, 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 style="overflow:hidden">+  // This function may be called only a small fixed amount of times per each<br>


+  // invocation, otherwise we do actually have a leak which we want to report.<br>
+  // If this function is called more than kGraveYardMaxSize times, the pointers<br>
+  // will not be properly buried and a leak detector will report a leak, which<br>
+  // is what we want in such case.<br></div></blockquote><div><br></div></div><div>Interesting. I didn't realize it was going to be *that* tightly bounded.</div><div><br></div><div>This makes me wonder if the whole disable free thing should just be removed at this point. </div>
</div></div></div></blockquote><div>I am all for it, --disable-free looks like a hack and we did not see any compile-time loss from removing it (measure on bootstrap).</div><div> </div><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Back in the day, we didn't so carefully use a BumpPtrAllocator in the ASTContext. Today, we might be fine to call free 10 times. </div></div></div>
</div></blockquote><div><br></div><div>But this is not 10 calls to free. This is 10-ish calls to delete, where the DTOR destructs other objects and so on. It may call much more than 10 frees.</div><div>Still, see above. </div>
<div> </div><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>Anyways, not trying to shift the goal posts; I mostly wanted to mention it in case someone gets some time to look into removing all of the leak stuff.</div><div class="im">
<div> </div><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 style="overflow:hidden">
+  static const size_t kGraveYardMaxSize = 16;<br>
+  static const void *GraveYard[kGraveYardMaxSize];<br>
+  static llvm::sys::cas_flag GraveYardSize;</div></blockquote><div> </div></div></div>Do these being function-local statics defeat the purpose of using a basic atomic increment? I can't recall if we correctly eliminate the cxa_guard in these cases...</div>
</div></blockquote><div>We will not have  cxa_guard here because there is no dynamic init -- both objects (the size and the array) are linker-initialized.</div><div>Atomic increment is here for the future case when clang becomes multi-threaded. </div>
</div><br></div></div>