Earlier quoted context omitted.
In heavily performance-engineered code having a GC coalesce memory is a pessimization in all cases. I've done a lot of performance engineering in both C++ and Java. Every optimization available in Java also exists in C++ but the reverse is not true, which is why C++ is always faster. Every example I have ever seen of Java being faster than C++ was just poorly optimized code. The heuristic I use is that heavily optimi…
What type and size of applications have you worked on? @pron, who works on the JVM and is a C++ expert, has been writing a lot recently about low level languages becoming increasingly impossible to optimize with more LOC and more people working on it (dozens, or even hundreds of developers). The idea being be a language with an aggressive JIT, moving garbage collector, and bump allocation is going to allocate/dealloc…
Almost all optimization is architectural in nature. Properly performance-engineered code allocates no memory after bootstrap. There is no possible way even in theory for a GC to outperform schedule-aware allocation from a fixed pool. In most cases the GC is just generic C++ code anyway; that indirection is unnecessary.
An important caveat is that I mostly deal with throughput-optimized code. It isn’t latency-sensitive and this article is about low-latency code. Nonetheless, the schedulers require predictable execution at ~1µs granularity for throughput optimization purposes, which is difficult to guarantee in Java.
I can write highly optimized code in C++ in a straightforward way that doesn’t really have a Java equivalent because equivalent guarantees are not provided as a practical matter.
TBH, even when I wasn’t trying to performance-engineer code I’ve never seen Java run as fast as the equivalent C++.