| > 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. |
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.