OSX is just like, "Hey guys, if any of you happen to not need your memory sometimes, would you mind kindly letting me know and I'll go ahead and let you go at a convenient time?" Meanwhile Linux goes on a murderous rampage with unpredictable effects.
... And Windows is sitting in a corner, fans kicked on high, trying valiantly to manage with swapping to disk until a sysadmin gives up trying to connect via RDC and yields to the age-old "have you tried turning it off and back on again?"
The part of this I hate most is that if you have physical access to the machine and can hit ctrl-alt-delete you are given an out-of-band dialog that functions flawlessly; this dialog happens to have a "task manager" button, but as the task manager functionality is part of a normal user application and not that magical dialog, you get thrown back into the swap storm, only now with yet another process (taskmgr) competing for memory :(.
That's a few layers up the stack. Sudden Termination is a message to the OS management layer that an app can recover robustly from an unexpected death. That's not a job for the kernel, and presumably Darwin has some handling analagous to the OOM killer for the situation where memory truly is exhausted.
FWIW: Android baked that idea into the framework from the start. All apps are essentially required by the application lifecycle to be robust against sudden failure, and the system is designed to give apps fair warning to save themselves at various times (e.g. on backgrounding). If you think about it, on a battery-powered embedded system that's pretty much a firm requirement anyway.
Android accomplishes this using a slightly modified OOM killer, which it can control directly through /proc. In addition to "out of memory condition" which traditional OOM killer supports, it has the "low memory killer" (LMK). Processes on Android that are not supposed to be randomly terminated are protected by adjusting the OOM/LMK settings, which the Android system does when launching Davlik for that activity/service.
This may have changed in recent version of Android, as I haven't kept up with internals that much.
Actually it's much more than slightly modified. The lowmemkiller (which is still present, and mostly unmodified from what you saw) code runs out of the cache shrinker framework, not on an OOM event. And it chooses processes to kill based on categories that correspond to UI state (e.g. preferentially killing idle apps before background processes before foreground apps, etc...).
But that's not quite what I was saying. The point was that the promise in OS X (that a process "could be killed if necessary") if baked into Android: it's true by default of all processes, and the framework guarantees a set of lifecycle callbacks to allow processes to persist their state robustly. This isn't part of kernel behavior at all.
The memory alert stuff on iOS is similar; when the phone runs low on free memory it tells the app free up as much as possible, and then only starts killing processes if there still isn't enough available.
It can be a bit finnicky to work with, but it does seem to be pretty much strictly better than just killing random processes without giving them a chance to be better behaved.
