[imtringued]

The problem with conventional garbage collection has very little to do with the principle or algorithms behind garbage collection and more to do with the fact that seemingly every implementation has decided to only support a single heap. The moment you can have isolated heaps almost every single problem associated with garbage collection fades away. The only thing that remains is that cleaning up memory as late as possible is going to consume more memory than doing it as early as possible.

[tuveson]

What problem does that solve with GC, specifically? It also seems like that creates an obvious new problem: If you have multiple heaps, how do you deal with an object in heap A pointing to an object in heap B? What about cyclic dependencies between the two?

If you ban doing that, then you’re basically back to manual memory management.

[paulddraper]

There’s a ton of work that goes into multi-generational management, incremental vs stop the world, frequency heuristics, etc.

A lot of the challenge is there is not just one universal answer for these, the optimum strategies vary case by case.

You are correct that each memory arena is the boundary of the GC. Any GC between them must be handled manually.

[grogers]

BEAM (i.e. erlang) is exactly that model, every lightweight process has its own heap. I don't see how you'd make that work in a more general environment that supports sharing pointers across threads.