> The whole point of moving collectors is that the can make the cost of memory management arbitrarily low If it was really true that "we can make the cost arb

> The whole point of moving collectors is that the can make the cost of memory management arbitrarily low If it was really true that "we can make the cost arbitrarily low" by simply delaying collection, that would be equivalent in the limit to not using GC at all and resorting to pure bump arena allocation. However as I mentioned, you can't really achieve this for long running programs. The chickens will always come home to roost: eventually the memory limit will be reached and you'll have to pay that collection cost in full. All that speeding up the mutation phase does is make you reach the limit even faster, compared to using heap allocation. Heap allocation may pay a small cost over time in CPU overhead (searching metadata for free memory ranges or taking locks, not doing huge memory copies - very limited impact on the memory subsystem!), but most such programs simply aren't CPU compute limited. That cost is almost free to them. The tradeoff in adding a memory copying/moving workload due to GC, even one that's invoked "rarely", is simply not worthwhile. Properly understood, they are well into the "pay more CPU compute cost in order to save on memory footprint and memory traffic" side of the tradeoff. I'm not dismissing the theoretical possibility that such cases may exist, but there's an argument that (1) they're surprisingly rare, and (2) even when they do apply, it's inherently unlikely that adopting tracing and moving GC would be a relevant knob, compared to increased use of plain old arenas or domain-specific ways of using more memory (such as caching). > Except it doesn't given the actual economics of RAM and CPU These economics have been heavily impacted by the RAMpocalypse. Tradeoffs that may have been valid to some extent back when that YouTube talk was given are no more applicable today.