Sigh. This again? A good garbage collector will always reach a higher throughput than "manual" dynamic allocation/deallocation in C/C++. Pauses are a different matter, and can impact latency; in cases where latency is crucial, Java programs either resort to manual memory management or use a commercial low-latency GC.
If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know that the latter can be done (and is often done) in Java too.
C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction. Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
You shouldn't really use the term "always" either. You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
> C++ gives you the option to just put your objects on the stack and have them clean themselves up upon destruction.
Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing.
> Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements.
A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects)
> You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
You have the same option in Java, too, and it's pretty much the same amount of work.
> Stack allocation is irrelevant for most of what the application is doing.
Well I disagree with that. In C++ it is quite common for most objects to be allocated on the stack. I have never heard stack allocation being described as irrelevant. Of course if the language puts everything on the heap then that statement might be true.
> In C++ it is quite common for most objects to be allocated on the stack.
Most objects? You have 64GB of RAM! You want to tell me that you can take advantage of all that RAM with thread stacks? You're unlikely to even use 4GB of stack.
If you don't, then you're talking about a small application.
If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know that the latter can be done (and is often done) in Java too.