2 ms·

Another interesting possibility for an immutable language would be a generational copying allocation with two young generations and no collection of the old gen

Another interesting possibility for an immutable language would be a generational copying allocation with two young generations and no collection of the old generation. Immutability would guarantee that you only have to scan the young generations, two young generations would catch practically all of the ephemeral garbage, and so long as they are small enough to fit a close level of cache, collection would be really fast.

dfox 10y ago
Immutable languages tend to produce more garbage in the old generation than mutable languages such that this approach is not going to work reasonably (easy to find useful piece of software written in mutable language that produces no garbage in the old generation, while any state changes in immutable languages will invariably produce garbage). On the other hand, generational GC is almost trivial to implement for immutable languages, exactly because there is no need for write-barrier. BEAM's GC is perfect example of how trivial can well performing GC be in that case (and good study material that is perfectly relevant for runtimes with mutable objects).