How is it difficult to handle?

    void* xmalloc(size_t s) {
        void *p;
        if (!(p = malloc(s)) {
            panic(“OOM”);
        }
        return p;
     }

If your process ran out of RAM, you get to quit. Why offload it on some other random process? This is how your database process runs out of memory, and your web workers get killed (or vice versa). In either case your system isn’t usable, but one is harder to debug.

In fact having the above in stdlib would have been just as effective at fixing thousands of little bugs and would have collectively saved us all thousands if not more man hours of developing the OOM killer and then raging online about it.

Because it's not necessarily your process that ran out of RAM. Imagine you have background process A which has allocated 1 GB of RAM just in case and never used it, and then process B tries to allocate maybe 100 MB, and the kernel says "No, I can't do that." Then process B quits. Is this really a better outcome than killing process A?

On my current laptop, pulseaudio has 2.7 GB virtual memory and 17 MB physical memory. If I open a new Firefox tab, I would much prefer for pulseaudio to die than for Firefox to die.

(You might say, "Well, pulseaudio shouldn't allocate 2.7 GB virtual memory," to which I'd say, "Sure, if you'd rather spend the thousands of hours fixing pulseaudio and every other program like it, go for it.")

Also, "panic" isn't a standard C function - are you envisioning a panic that unwinds or one that doesn't? If it unwinds, what happens if you need to allocate memory during the unwind to save state? If it doesn't, why is it a better state of the world for Firefox to crash periodically and require me to recover my work, without even giving it the option to synchronize its state?

> pulseaudio has 2.7 GB virtual memory

heh, anything compiled with GHC allocates a TERABYTE of virtual memory, good luck running that w/o overcommit

Malloc may very well succeed when there is not enough free memory in the system. You'll only know it when you try to write to memory and the system runs out of real memory to back your virtual memory.

This can happen much later in time.

Memory allocated by malloc is not necessarily there by the time you need it.

Another issue is that a fork will simply copy the task state and set all the pages to 'copy on write' in the clone. That way the fork can execute very rapidly and only when the child process starts writing pages is there some actual memory overhead.

Well, what about adding a new signal (SIGXMEM) with a default action of ignore? If the system is running low on memory it can send this to some or all processes and wait for a little bit to see if things get better.

This is how iOS has handled things since version 2.0: https://developer.apple.com/documentation/uikit/uiapplicatio... > It is strongly recommended that you implement this method. If your app does not release enough memory during low-memory conditions, the system may terminate it outright.

See section 11 "Memory Pressure" of https://www.kernel.org/doc/Documentation/cgroup-v1/memory.tx... - there's a way to get notified via eventfd() if your current cgroup's memory gets low. I believe you can just do this on the root memory cgroup (/sys/fs/cgroup/memory/memory.pressure_level) if you're not setting up actual cgroups for your application.

(Signals for asynchronous conditions are an awkward interface because they can interrupt you between any two assembly instructions. You're not able to release memory in the handler itself; you have to set a flag that gets handled by the main loop. So eventfd makes sense here. I'm assuming iOS is doing something similar by queueing an Objective-C method call. Signals make a lot more sense for segfaults and the like, where you're being interrupted at the exact instruction that isn't working and you need to handle it before executing any more instructions.)

It's a good idea.