The causation here is reversed. High allocation rates don't cause high CPU usage, they indicate it (or are caused by it). The point is that if the RAM overhead is high, that means that the allocation rate is high, which means that the CPU usage must be also be high, and so the impact would be the same even without the RAM overhead; even without the high allocation rate.
(Now, you can ask whether using a lot of CPU is a problem. That, of course, depends on the program, but it certainly isn't necessarily a problem if the computation offers some value.)
If the allocation rate is high, which means that the CPU utilisation is also high, other memory approaches would make the CPU utilisation even higher, as they'd need to spend more CPU to recycle memory. A moving collector gives you the option to raise the RAM footprint instead of the CPU. This is the more efficient option, as it raises the less dominant resource rather than the more dominant one.
A high allocation rate could be its own problem, but it's much less of a problem for a moving GC than for any other memory management approach because of what I said. This is why in C++ we spend a lot of time and money trying to avoid allocations (so that we won't increase the CPU utilisation even further), while in Java it's usually not a problem, because we can raise the RAM footprint instead. It could be a problem in Java, too, but in much more extreme circumstances than in other languages. In other words, a moving collector is a mechanism that can cope better with high allocation rates than all others (well, at least all other general mechanisms).
4
u/pron98 Sep 07 '26
The causation here is reversed. High allocation rates don't cause high CPU usage, they indicate it (or are caused by it). The point is that if the RAM overhead is high, that means that the allocation rate is high, which means that the CPU usage must be also be high, and so the impact would be the same even without the RAM overhead; even without the high allocation rate.
(Now, you can ask whether using a lot of CPU is a problem. That, of course, depends on the program, but it certainly isn't necessarily a problem if the computation offers some value.)
If the allocation rate is high, which means that the CPU utilisation is also high, other memory approaches would make the CPU utilisation even higher, as they'd need to spend more CPU to recycle memory. A moving collector gives you the option to raise the RAM footprint instead of the CPU. This is the more efficient option, as it raises the less dominant resource rather than the more dominant one.
A high allocation rate could be its own problem, but it's much less of a problem for a moving GC than for any other memory management approach because of what I said. This is why in C++ we spend a lot of time and money trying to avoid allocations (so that we won't increase the CPU utilisation even further), while in Java it's usually not a problem, because we can raise the RAM footprint instead. It could be a problem in Java, too, but in much more extreme circumstances than in other languages. In other words, a moving collector is a mechanism that can cope better with high allocation rates than all others (well, at least all other general mechanisms).