Why does Erlang use generational (per-process) garbage collection instead of a single global GC?

A single global collector would need to pause every process on the node at once to safely scan and compact memory, which directly conflicts with Erlang's goal of soft real-time responsiveness — a telecom switch or messaging backend can't tolerate a multi-hundred-millisecond global pause just because one process allocated too much data.

By giving each process its own private heap, the BEAM can collect one process without touching anyone else's memory or execution, keeping collection pauses small, local, and predictable. The generational split (young vs old data) further reduces work per collection, since most allocations in typical Erlang code are short-lived (temporary variables inside a function call), so scanning only the young generation most of the time is far cheaper than rescanning everything.

The tradeoff is that shared, cross-process references aren't possible the way they are in a shared-heap runtime — which is exactly why message passing between processes has to copy data rather than share a pointer.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.