3 ms·

I don't know of any direct comparisons of JVM and Go GC efficiency. However, the biggest difference is that there's only one Go GC, while there are several sup

I don't know of any direct comparisons of JVM and Go GC efficiency. However, the biggest difference is that there's only one Go GC, while there are several supported ones for Hotspot. With the exception of CMS, which is deprecated, those collectors occupy different niches, meaning there are times you'd use each of them.[0] The Go collector is optimized for relative simplicity and low latency, and currently tolerates significant overhead to hit that target. [0] Maybe Shenendoah and ZGC are close enough that they're just direct competitors? Perhaps they're even designed to supercede G1? I'm not quite sure about that, but even so, it would leave at least 2-3 options, depending on whether you include Serial/Epsilon as serious options.

pron 7y ago
Go's collector is similar to OpenJDK's deprecated (about-to-be-removed) CMS (applied to the entire heap, rather than just the old generation, as in OpenJDK). They're both concurrenct non-moving mark and sweep collectors.
HALtheWise 7y ago
It's fundamentally difficult to compare them, because the features of the language itself change the workload the GC faces in a typical program. For example, Java boxes almost all values, so can't store very much on the stack. That means that conventional Java programs (typically) generate many more short-lived heap allocations than Go programs. For more, see the excellent blog post here: https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote
- hyperpape 7y ago
  I haven't put real thought into this, but it seems that in principle, given enough understanding of the runtimes, you can create good benchmarks of the collector. You would have to find patterns that force it to allocate/collect similar amounts of data, but that's doable. However, to your point, so far as the languages tend to allocate more or less data on the heap, that might change which benchmarks look good, the same way that you'll care about different automotive benchmarks if you want to tow a trailer or race.
hilbertseries 7y ago
It's also a little difficult to benchmark Go GC the way you can the JVM, because you can't set a maximum heap size in Go. So, if you create objects too fast you'll just run out of system memory.

pron 7y ago

Go's collector is similar to OpenJDK's deprecated (about-to-be-removed) CMS (applied to the entire heap, rather than just the old generation, as in OpenJDK). They're both concurrenct non-moving mark and sweep collectors.

HALtheWise 7y ago

It's fundamentally difficult to compare them, because the features of the language itself change the workload the GC faces in a typical program. For example, Java boxes almost all values, so can't store very much on the stack. That means that conventional Java programs (typically) generate many more short-lived heap allocations than Go programs. For more, see the excellent blog post here: https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote

hyperpape 7y ago
I haven't put real thought into this, but it seems that in principle, given enough understanding of the runtimes, you can create good benchmarks of the collector. You would have to find patterns that force it to allocate/collect similar amounts of data, but that's doable. However, to your point, so far as the languages tend to allocate more or less data on the heap, that might change which benchmarks look good, the same way that you'll care about different automotive benchmarks if you want to tow a trailer or race.

hilbertseries 7y ago

It's also a little difficult to benchmark Go GC the way you can the JVM, because you can't set a maximum heap size in Go. So, if you create objects too fast you'll just run out of system memory.