<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 27, 2013 at 3:01 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Dec 27, 2013 at 11:44 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 dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">

<div>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>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><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></div></blockquote><div><br></div>

</div><div>I take these my words back. Building 483.xalancbmk with -O0 (make -j32) shows around 0.5%-1% compile-time difference:</div><div>with -disable-free :</div><div><div>TIME: real: 8.140; user: 177.970; system: 13.180</div>

<div>TIME: real: 8.070; user: 177.940; system: 13.090</div><div>TIME: real: 8.103; user: 177.960; system: 13.410</div><div>TIME: real: 8.122; user: 178.110; system: 13.180</div><div>TIME: real: 8.093; user: 177.660; system: 13.210</div>

</div><div>without -disable-free :<br></div><div><div>TIME: real: 8.140; user: 179.750; system: 13.260</div><div>TIME: real: 8.113; user: 178.770; system: 13.710</div><div>TIME: real: 8.101; user: 179.830; system: 13.180</div>

<div>TIME: real: 8.262; user: 180.160; system: 12.760</div><div>TIME: real: 8.125; user: 179.510; system: 13.070</div></div><div><br></div><div>0.5% may be worth this relatively innocent hack. </div></blockquote></div><br>
Yea, I think we could fix this by making the ASTContext's destructor do less work ... but whatever, this patch LGTM. =]</div></div>