Concurrent GC: a good thing?
On the benefits of spawning a OS new process for concurrency:
This is quite a different approach to concurrency and, in particular, each new process has its own GC.
This is how Erlang works except it uses it's own flyweight processes, not OS processes. And it's absolutely key to Erlang's concurrency, reliability and soft-realtime performance.
Each Erlang process has it's own mini-heap, which helps reduce heap fragmentation overall. Because of Erlang's functional nature, cycles in data-structures are not possible, meaning GC is a much simpler problem. Also completed/failed processes don't need to be GC'd at all, the heaps are simply freed en-mass back to the Erlang VM.
Contrast to shared state threading like Java where the object graph can become a giant tangled ball, any object in any thread can hold a reference to anything else. This why so many Java applications that perform great in benchmarks often slow to a crawl under real world conditions (and why micro benchmarks are one of the worst criteria for choosing a programming language).
Posted June 12, 2007 1:28 PM