Return to Answer

• on a managed heap, dynamic allocations can be done much faster
• shared ownership can be handled with negligible amortized cost, where in a native language you'd have to use reference counting which is awfully expensive
• in some cases, object destruction is vastly simplified as well (finalizers only have to run in a few cases, where in C++ destructors must always be executed)

• on a managed heap, dynamic allocations can be done much faster
• shared ownership can be handled with negligible amortized cost, where in a native language you'd have to use reference counting which is awfully expensive
• in some cases, object destruction is vastly simplified as well (Most Java objects can be reclaimed just by GC'ing the memory block. In C++ destructors must always be executed, and nearly every object has one)

The problems with garbage collectors are twofold:

• While on average a garbage collector performs better, you lose some control over when to take the performance cost. Manual memory management ensures your thread won't ever be halted while waiting for memory to be cleaned up. A garbage collector can, at almost any time, decide to pause the process and clean up memory. In almost all cases, this is fast enough to be no problem, but for vital real-time stuff, it is a problem.

The main problem with a GC is that while on average a garbage collector performs better, you lose some control over when to take the performance cost. Manual memory management ensures your thread won't ever be halted while waiting for memory to be cleaned up. A garbage collector can, at almost any time, decide to pause the process and clean up memory. In almost all cases, this is fast enough to be no problem, but for vital real-time stuff, it is a problem.

(An additional problem is that you lose a bit of expressiveness. In C++, RAII is used to manage all sorts of resources. In Java, you can't use RAII. Instead the GC handles memory for you, and for all other resources, you're screwed, and have to do it yourself with lots of try/finally blocks. There is no reason why RAII couldn't be implemented in a GC'ed language, but it's not available in either Java or C#)

There is no JVM interpreter as such, and hasn't been for several versions. The Java bytecode is JIT'ed on the fly. (Technically it still interprets some of the code, but anything that matters performance-wise gets JIT'ed)

If you take a C++ program and translate it to Java, that too will also run slower.

Java isn't an interpreted language, and hasn't been for several versions. The Java bytecode is JIT'ed on the fly. (Technically it still interprets some of the code, but anything that matters performance-wise gets JIT'ed)

If you take a C++ program and translate it to Java, that too will also run slower.

Not because one language is "faster" than the other, but because the original program was written for one language, and was tailored to work well in that language. And any attempt to translate it to another language will lose this advantage. You end up with a C++-style Java program, which won't run efficiently on the JVM, or a Java-style C++ program, which will run terribly as well.