<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 3, 2016 at 12:23 PM, Yury Mikhaylov <span dir="ltr"><<a href="mailto:yury.mikhaylov@gmail.com" target="_blank">yury.mikhaylov@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 class="gmail_quote"><span class=""><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 class="gmail_quote"><span><div>LLVM shouldn't replace new with new(std::nothrow), it should just abort.</div></span></div></div></div></blockquote></span><div>Does it? When we were evaluating embedding LLVM a few years back, that was one of the major pain points for us. Something goes wrong and LLVM/Clang calls abort, crashing the whole program. Library shouldn't make these type of decisions lightly: return an error, throw an exception, fire up a smoke signal - whatever - but there's just not enough context to decide right at that level.</div></div></div></div></blockquote><div><br></div><div>I agree you could make that argument for many of the places LLVM uses assert() today. LLVM uses assert not just in checking invariants, but as an error handling mechanism.</div><div><br></div><div>However, the level of extra complexity that would be required in order to try to handle *memory allocation failure* is not worth it. Not even close to worth it. There's only VERY limited classes of programs where that is a worthwhile thing to try to do (example: PID 1). A compiler library isn't one of them.</div><div><br></div><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 class="gmail_quote"><span class=""><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 class="gmail_quote"><span><div>There's effectively zero chance the codebase will ever be able to recover from OOMing, and with modern OSes, you're almost never going to actually see a malloc failure until it's way too late, anyways.<br></div></span></div></div></div>
</blockquote></span></div>IMO the best way is to allow user to specify their own allocation strategy with default fallback to std::new: JITs have bursts of activity between longer quiet periods and may want to defer memory cleanup until later; IDE with code completion may want to keep memory consumption in check and choose to disable whole feature, rather than impede other processes; and so on.</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"></div></font></span></div></blockquote></div><br></div><div class="gmail_extra">The global operator new is already overridable per the C++ standard. And, malloc/free themselves are overridable, in practice, on common systems. LLVM doesn't need to do anything special to allow users to plug in their own allocator if they want to.</div><div class="gmail_extra"><br></div></div>