<div dir="ltr"><div dir="ltr">On Tue, Sep 21, 2021 at 4:11 PM Arthur Eubanks <<a href="mailto:aeubanks@google.com">aeubanks@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I haven't looked too much into the -disable-free stuff, but the reason it mitigates crashes is because if we clear AST objects we still have dangling references to them that we later attempt to clean up unless we -disable-free.<br></div></div></blockquote><div><br></div><div>So disabling free is keeping more things alive - perhaps then the RAM savings aren't as much as they could be if freeing was enabled? But yeah, more to look into.</div></div></div></blockquote><div>-disable-free only disables freeing things right before we exit to save some runtime during teardown (since the kernel freeing things is probably faster than the userspace allocator freeing things), so it shouldn't affect the amount of memory savings we get.</div></div></div></blockquote><div><br>Right right, fair enough. (still worries me a bit - reflects that we might be creating a less-than-library-usable code change, which would be best avoided given all the interesting uses of clang as a library)<br> </div></div></div>