Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 15, 2020 2:33 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 14, 2020 1:58 pm wrote:
> > Without overcommit, anything that could cause OOM
> > will probably tell you immediately (ENOMEM in C, std::bad_alloc exception in C++,
> > OutOfMemoryError exception in Java, etc) which makes it fairly trivial to detect.
>
> If an allocation fails then it's way to late to do something about it. Unless your software is completely
> trivial whatever failure path you have might need to allocate something - even only to inform other parts
> of the system that you ran out of memory - and that might fail too. You could also end up in a situation
> where some allocations fail and some succeed leaving objects in an incomplete state. Show me code that
> handles that kind of scenario properly in a non-trivial application or I won't believe it exists.

Probably for an application, the best way is not to return 0 to malloc() but to pause that application for some time in the hope that memory will be available within few seconds (or less). Nobody ever said malloc() would be atomic / would reply quickly, and you should not have an application mutex before calling that (or may block other threads).
For kernel and drivers software, the problem of not having memory is completely different.

Note that OOM killer due to lack of physical memory may happen more now that we have 32 cores with max 64 Gbytes physical memory... an application parallel compilation can do it, I tried...