Strongly disagree. First of all, we're talking about miniscule (usually Kb or less) amounts of memory here. Secondly, I'm not talking about over-allocating so p

Strongly disagree. First of all, we're talking about miniscule (usually Kb or less) amounts of memory here. Secondly, I'm not talking about over-allocating so programs can run in perpetuity; rather, I'm talking about keeping some small ballast around so cleanup and reporting can happen right before my program crashes/halts (think: the kind of code you'd put in atexit hooks). That's a better experience for operators and product maintainers than "your app disappeared without a trace because the OOM killer came for it" or "your app disappeared without a trace because its ENOMEM behavior was abort()". This is absolutely not why Java had/has a bad rap memory wise--that has more to do with a combination of code that allocates irresponsibly on the happy (not memory-error-anticipating) path, and the JVM's preference to preallocate as much as possible for every purpose, not just OOM handling. > Just make use of proper libraries that will invalidate caches if needed What if I've dumped every cache I can and I'm still getting allocation (or spawn, or whatever) errors because the system is out of memory? It's useful to have a contingency in place to turn out the lights room-by-room rather than cutting power to the whole building, as it were.