<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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=""><div>LLVM shouldn't replace new with new(std::nothrow), it should just abort.</div></span></div></div></div></blockquote><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><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=""><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></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><div class="gmail_extra"><br></div><div class="gmail_extra">- Yury</div></div>