Well no because in a manual memory management language if you allocate 1 object, and then destroy it, and then reallocate another object then you've used 1 obje

Well no because in a manual memory management language if you allocate 1 object, and then destroy it, and then reallocate another object then you've used 1 object amount of memory. In Java, that's two objects, and one will be collected later. What this means is that a C++ application running at 90% memory usage is going to use about the same amount of work per allocation/destruction as it would at 10% usage. The same IS NOT true for GC languages. At 90% usage, each allocation and deallocation will be much more work, and will trigger collections and compactions. It is absolutely true that GC languages can perform allocations cheaper than manual languages. But, this is only true at low amounts of heap usage. The closer you get to 100% heap usage, the less true this becomes. At 90% heap usage, you're gonna be looking at an order of magnitude of slowdown. And that's when you get those crazy statistics like 50% of program runtime being in GC collections. So, GC languages really run best with more memory. Which is why both C# and Java pre-allocate much more memory than they need. And, keep in mind I'm only referring to the allocation itself, not the allocation strategy. GC languages also have very poor allocation strategies, particularly Java where everything is boxed and separate.