I work on analytical data engines. Lots of spatial and graph-like joins on PB-to-EB scale data models often concurrent with extremely high rates of real-time ingest into the same data model. I’ve also done a lot of work in HPC and more conventional databases at smaller scales. Typical code base is in the range of 100k-1M LoC in C++. Java has more LoC equivalent but it isn’t used much for these applications anymore because it scales significantly worse as systems and hardware become larger.

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