2 ms·
This is a reasonable question, so I’m unsure why it’s downvoted. It usually makes sense to talk about the memory overhead of the JVM itself, rather than talkin
by klodolph 7y ago
This is a reasonable question, so I’m unsure why it’s downvoted.
It usually makes sense to talk about the memory overhead of the JVM itself, rather than talking about one of the languages specifically, like Java or Kotlin (but maybe Scala and Clojure are a bit different).
The tradeoffs for GC systems are complicated and not easy to understand. Go supports only one GC system, as far as I know, which does not move memory and attempts to minimize GC pauses. It sacrifices throughput and CPU utilization to achieve this.
The JVM can be tuned in many ways and there are a number of different options, from choosing different GC algorithms to different memory models. Most JVM algorithms will compact memory. Some are optimized for throughput and others are optimized for shorter pauses.
In practice, my observation is that Go’s GC pauses are, out of the box, shorter than what most people will get by tuning the JVM. This is probably the most critical property for writing backend services with high fanout, which is very common at places like Google.
- Gibbon1 7y agoI don't have a dog in this be cause all I do is write embedded firmware and crummy tools that run under windows. But low latency is a better choice than throughput most of the time. My gut says when a system bogs down failures due to latency hits you first.
- klodolph 7y agoI’m gonna go ahead and say that this is one of the reasons why people like Go so much. Latency is a big problem and becoming bigger as fanout increases, so the old defaults for tuning GC turn out to suck horribly. However, the throughput penalty is very real and e.g. compiling a large codebase I’d much rather have throughput tuning.