Hacker News Reader

Comment by sterwill | Hacker News Reader

Does this result in programs more frequently erroring/crashing because they can't allocate? I don't know how well many of the programs I frequently use on my desktop (Firefox, GNOME desktop, JVM + IntelliJ, Slack, etc.) handle allocation failures. I'm not sure they would do much better than crash, but I know the default OOM killer settings work well for me. About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed, and that's fine with me.

View on HN

Java allowed to handle out-of-memory rather well if one wanted to even 25 years ago. Basically one allocated a buffer on a startup taking 5% of memory that the application was supposed to use and made all threads to catch the oom exception. When handling that the buffer would be released, GC would be forced and a special flag would be set asking app to cancel any memory-intensive tasks until enough memory would be released and the buffer can be allocated again. It worked extremely well.

Yeah, crash ballast is an extremely underrated tool.

It also works for the OOM killer: run a daemon with a child process that holds some fixed amount of memory. Adjust OOM scores of everything else on the system lower than the child. If the parent’s waitpid() returns due to an OOM kill, send an alert/shutdown nonessentials/sync buffers to disk and so on.

Maybe you should skip running a useless child process and just use PSI to monitor memory pressure.

PSI polling is also good, but there’s no substitute for knowing for sure that the OOM killer is awake and hunting.

You can't know when the OOM killer is awake and hunting. The kernel doesn't know that.

The approach I originally described provides a useful early warning system for that condition. It’s not perfect, but has proven useful and better than nothing many times.

> Does this result in programs more frequently erroring/crashing because they can't allocate?

I run Firefox, VSCodium with LSP, Discord, Signal and there's still space left for a game like CS2. I'm not a heavy user by any means.

> I'm not sure they would do much better than crash

I have yet to see a program that silently handles allocation failures and doesn't crash. These days everything is coded to crash if no memory :(

> About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed

In my case it killed system critical processes with no way to recover. With disabled overcommit, it freezes for a while (usually for a minute or two), I close some random program of my choosing and then see in Resource Monitor what's eating my ram.

> I have yet to see a program that silently handles allocation failures and doesn't crash

Postgres handles allocation failures

Reply on news.ycombinator.com