> It is most definitely not low latency for heap sizes as big as what the OpenJDK can routinely handle (up to a terabyte).

A claim without evidence isn't worth very much.

> Go’s GC has it easier due to the language having native support for stack-based allocation which can sometimes be used in otherwise garbage-heavy places.

Java (i.e., "modern JVMs") also has "native" stack-based allocation (indeed, it has an escape analyzer whose sole purpose is putting things on the stack); however, it lacks value types.

Yes it has escape analysis, but even if it were perfect and correctly recognize every possible pattern, it is still nothing compared to having native support for it in the language and mandate it’s usage throughout the codebase.

One can easily add a single line and “break” the escape analysis, while it is compile time checked with value types.

Go doesn’t have semantics for stack allocation, it also has escape analysis. It’s pretty easy to intuit about the escape analysis, but you have to profile to be sure.

The issue with Go's GC on big heaps is not getting high latency - it is always low latency - but rather the murderous throughput and memory overhead impact.