Gdy maszyna wirtualna Erlang działa w sytuacji braku pamięci, po prostu powoduje awarię całej maszyny wirtualnej. Powodem jest to, że jest to najprostsza i najbezpieczniejsza rzecz.
Jeśli potrzebujesz systemu odpornego na awarie, musisz mieć już więcej niż jeden komputer. Nie można stworzyć systemu odpornego na awarie tylko z jednym komputerem (precyzyjnie autonomiczna jednostka obliczeniowa). Jeśli więc twoja aplikacja działa w sytuacji braku pamięci, najprościej jest pozwolić na awarię całej maszyny wirtualnej. W każdym razie masz błąd w swoim systemie.
Obsługa wszystkich skrzynek brzegowych - których brak pamięci można obsłużyć, a których nie można - jest zbyt skomplikowana i podatna na błędy. Zabicie obraźliwego procesu nie jest rozwiązaniem. Po pierwsze, który jest procesem obrażającym, trudno jest zdecydować. Zabicie jakiegoś "przypadkowego" (heurystycznie zdecydowanego) procesu nie jest ani rozwiązaniem, ponieważ ten proces zabity przez heurystykę może być procesem odpowiedzialnym za odzyskanie przez przypadek. Zabicie całej maszyny wirtualnej jest nie tylko najprostszym, ale także jedynym rozsądnym rozwiązaniem sytuacji braku pamięci.
Sposób, w jaki jest to wykonywane w większości nowoczesnych popularnych języków lub systemów operacyjnych, jest zdecydowanie niewłaściwy w sytuacjach, w których potrzebne są niezawodne systemy. Może być akceptowalny dla komputerów stacjonarnych lub mniej rygorystycznych wymagań, ale absolutnie nie do przyjęcia dla systemów, dla których przeznaczony jest Erlang.
Zobacz też: [Dlaczego Erlang zawiesza się na dużych sekwencjach?] (Http://stackoverflow.com/questions/192725/why-is-erlang-crashing-on-large-sequences) –