I liked the article. It was a simplified explanation, which is a good thing in its own right: not everyone reading it cares about the gory details. I'll prov

I liked the article. It was a simplified explanation, which is a good thing in its own right: not everyone reading it cares about the gory details. I'll provide some such details for the curious, though. Technically, malloc() is not a system call; it is a library function that calls either brk()/sbrk() or mmap() (or just uses memory it already "has"). The choice depends on the situation and just what it's doing. mmap() engages the VM subsystem, backing a chunk of RAM with part of a given file on disk (in this case with a special flag to not actually do that, but just give the RAM). Of course this will never require actual RAM until you go to use it: that's the whole point of the call. Normally mmap() will not cause OOM issues, because it creates exactly as much virtual memory out of thin air as it requests physical memory. That's not true in this usage, though. I suppose in this usage, it could block off a chunk of virtual memory. brk() and sbrk() are the more "normal" ways to get extra memory, by expanding the heap. The new memory must be initialized manually (or not, as the runtime prefers). The main reason to not do this all the time is that the heap itself must be contiguous. Using mmap() lets malloc() return pages to the system under more varied conditions and work around parts of the address space that contain other things[1]. Calls to mmap()/brk()/sbrk() are rather expensive compared to malloc() calls. They are system calls, after all. That's why programs will normally ask for more memory than they actually need at the moment: it reduces the amortized runtime cost of malloc(). Linux tries to take advantage of this. So, the strange Linux behavior is that if a process calls mmap()/brk()/sbrk() (and doesn't hit the addressable limit) Linux will simply record that the process has requested mapping of a particular region of memory. Then, later, the VM subsystem hands out the memory when the process tries to do something to it. The question is, what to do if there isn't any memory to hand out? There's no way to cause an arbitrary memory access to fail with ENOMEM, so Linux has this hacky workaround where it semi-arbitrarily selects and kills something. The historical way to avoid this was to have a huge amount of virtual memory, hence the suggestions like "twice the amount of RAM in the system". The system would become unusably slow before the OOM killer would engage, and the user would manually kill some relatively unimportant processes. [1]- In older versions of the Linux kernel, the program code would be stored in memory about 1G away from the heap. So, as soon as you used about 1G, you'd run into your code and malloc() would no longer be able to brk() for more memory.