Question

With the "let it crash" philosophy of Erlang, one would expect the entire VM not to crash if a process cannot allocate the memory needed to proceed with its operations; indeed, if the system had a heuristic to kill some process to free some memory, some other process would handle this and recover. Root supervisors would probably be unlikely to be killed by the heuristic.

This is in direct contrast to most modern popular languages which just die or let the OS choose what to do.

How is running out of memory actually handled in Erlang?

Was it helpful?

Solution

When Erlang VM runs in an out-of-memory situation it simply crashes the whole VM. The reason is it is the most simple and safe thing to do.

If you want a fault tolerant system, you have to have more than one computer already. You can't make a fault tolerant system with only one computer (autonomous computation unit precisely). So if your application runs in an out-of-memory situation the simplest thing is to let the whole VM crash. You have a bug in your system anyway.

Handling all edge cases - which out-of-memory you can handle and which one you can't - is too complicated and error prone. Killing the offending process is not the solution. First, which is the offending process is hard to decide. Killing some "random" (heuristically decided) process is neither a solution because this process killed by heuristic could be the process responsible for recovery by accident. Killing the whole VM is not only the simplest but also the only reasonable solution to an out-of-memory situation.

The way it is done in most modern popular languages or OS is definitely wrong in situations where you need reliable systems. It can be acceptable for desktop or less strict requirements but absolutely unacceptable for systems which Erlang is designed for.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top