Erlang and the BEAM VM: Actor Concurrency, OTP Supervision Trees, and Fault Tolerance

Developed at Ericsson in the late 1980s by Joe Armstrong, Robert Virding, and Mike Williams to power telecommunications switches, Erlang was engineered with a radical design requirement: systems must achieve "Nine Nines" ( $99.9999999\%$ ) availability, operating continuously through hardware faults, network partitions, and software bugs without downtime.

This guide provides deep technical coverage of the BEAM Virtual Machine, the Share-Nothing Actor Model, OTP (Open Telecom Platform) Generic Behaviors, and Supervision Tree Hierarchies.

1. Quick-Reference: BEAM VM vs. JVM vs. OS Threads

+-----------------------------------------------------------------------------------------------------------------------+
|                                           CONCURRENCY RUNTIME COMPARISON                                              |
+-----------------------------------------------------------------------------------------------------------------------+
| Runtime Feature        | Erlang BEAM Process                    | Java Virtual Thread (Loom) | OS Native Thread (Pthread)|
+------------------------+----------------------------------------+----------------------------+------------------------+
| Memory Footprint       | ~ 300 Bytes per process                | ~ 1 KB                     | ~ 1 MB - 8 MB          |
| Concurrency Scale      | Millions of concurrent processes       | Millions of virtual threads| Thousands per server   |
| Memory Model           | Share-Nothing (Isolated per-proc heap) | Shared Heap                | Shared Memory          |
| GC Pauses              | Per-process (Zero global STW pauses)   | Global STW pauses (G1/ZGC) | Manual / None          |
| Preemption Invariant   | Reduction counting (Fair preemption)   | Cooperative at blocking IO | OS Kernel Time-slice   |
| Fault Containment      | Process crash isolated; supervisors heal| Uncaught uncaught crashes JVM| Segfault terminates app|
+-----------------------------------------------------------------------------------------------------------------------+

2. BEAM Process Architecture: Reductions & Isolated Heaps

Unlike operating systems where processes share memory through complex locking, every BEAM process is an isolated actor with its own:

Private Heap: Garbage collection operates independently per process. When a short-lived worker process finishes, its entire heap is reclaimed instantaneously without triggering global GC sweeps.
Mailbox: An unbounded FIFO message queue storing immutable binary messages.
Reduction Budget: The BEAM scheduler allocates a fixed budget of 4,000 Reductions (roughly function calls) per time slice. When the budget expires, the scheduler preempts the process, ensuring no single CPU-bound compute loop can starve I/O workers.

                    BEAM VM Multi-Core Scheduler Pool
                    +-------------------------------+
                    | Scheduler Core 1  | Core 2    |
                    +---------+---------+-----+-----+
                              |               |
                              v               v
                   [ Process A ]         [ Process B ]
                   (Heap: 4 KB)          (Heap: 12 KB)
                   (Mailbox: [M1, M2])   (Mailbox: [])
                         |                     ^
                         | Send Message (!):   |
                         +---------------------+
                         (Deep copied across heaps,
                          or zero-copy Refc Binary >64B)

3. The OTP Supervision Hierarchy: "Let It Crash"

In Erlang philosophy, attempting to defensively anticipate every conceivable edge case via nested try/catch handlers leads to fragile, bloated code. Instead, Erlang embraces "Let It Crash": processes fail fast, while structured Supervisors automatically restart them in clean, known-good states.

                        [ Root Supervisor ]
                                 |
                 +---------------+---------------+
                 |                               |
                 v                               v
       [ Worker Supervisor ]           [ DB Connection Pool ]
                 |
        +--------+--------+
        |                 |
        v                 v
   [ Worker 1 ]      [ Worker 2 ]
   (Crashes!)        (Healed by one_for_one strategy)

Common Restart Strategies

one_for_one: If a child process crashes, only that child is restarted.
one_for_all: If any child crashes, all sibling processes in the supervisor group are terminated and restarted (essential for tightly coupled state machines).
rest_for_one: If a child crashes, only subsequent siblings defined after it in the startup order are restarted.

References

Armstrong, J. (2007). Programming Erlang: Software for a Concurrent World. Pragmatic Bookshelf.
Virding, R., Wikström, C., & Armstrong, J. (1996). Concurrent Programming in ERLANG (2nd ed.). Prentice Hall.
Däcker, B. (2000). Concurrent Functional Programming for Telecommunications: A Case Study of Technology Introduction. Licentiate Thesis, KTH.