> Also, GCs have other advantages, such as a much higher memory allocation-reclamation throughput than any general manual scheme A benefit of using C/C++ is th

> Also, GCs have other advantages, such as a much higher memory allocation-reclamation throughput than any general manual scheme A benefit of using C/C++ is that you are not limited to general schemes. If you have an allocation/deallocation hotspot, you can use more specialized schemes like arena allocation, which will beat a GC handily. Also, latency and predictability are often more important than throughput. GCs fare poorly on these counts. > forget about safepoints - C++ doesn't even have a memory model, or didn't until C++11 Aka it does have a memory model. And one of the points Doug Lea made in the talk you linked is that the Java memory model is actually broken and no one knows how to fix it, whereas C++'s is not (though it's broken in ways that apparently don't affect anyone). > Also, if you think you're not "giving up control" in C++ (or C; or Assembly), then you're sorely mistaken. You have little or no control over ILP, prefetching, branch-prediction, outstanding cache misses and all the magic modern CPUs do at runtime. This is a tired and weak argument. A mispredicted branch costs 5ns. A main memory reference (cache miss) costs 100ns. And you actually have a lot of control over these things; you can make your branches more predictable and the working set of your tight loops smaller so it will fit in cache. And there are actually instructions that give control over prefetching. A Java GC pause on the other hand is often on the order of 200ms. That's six orders of magnitude in difference, and can be even longer in degenerate GC situations. There is really no bound to the worst case. The loss of control also comes from the fact that the effects are highly nonlocal. If your C/C++ code is in a tight loop, the microarchitectural effects are mostly a function of your own code and its behavior. But whether a safepoint triggers a GC pause in Java is a function of the entire program's behavior. So you really can't equate these two things. Java's loss of control is many orders of magnitude larger and less local. > But this inlining capabilities of the JVM is why it often outperform C++ even in single-threaded code. I don't think you've made this case at all. > All in all, Java usually comes up ahead in large codebases Coincidentally it is large codebases where it is most difficult to compare apples to apples, because it is so unlikely that you can really get two large programs that do the same thing with the same design. I'm deeply skeptical of this claim. > and falls behind in specific use cases (mostly numeric HPC). Java falls behind it tons of cases. It loses in nearly all of the benchmarks game, only some of which are numeric: http://benchmarksgame.alioth.debian.org/u64q/java.php http://benchmarksgame.alioth.debian.org/u64q/java.php It loses very badly in this benchmark published a few years ago by Google, which is not numeric: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/37122.pdf http://static.googleusercontent.com/external_content/untrust... Given comparable programs, C++ is nearly always faster. You really haven't offered any evidence that contradicts this basic fact. The only benchmark you cited didn't even have any C++ programs in it.