3 ms·

Generational garbage collection doesn't help much with a language with value types, stack allocation, and decent escape analysis. “It isn't that the generation

Generational garbage collection doesn't help much with a language with value types, stack allocation, and decent escape analysis. “It isn't that the generational hypothesis isn't true for Go, it's just that the young objects live and die young on the stack. The result is that generational collection is much less effective than you might find in other managed runtime languages” https://twitter.com/davecheney/status/1019430967054819328 https://twitter.com/davecheney/status/1019430967054819328 Go's GC improvements are revealed in P99.9 latencies of servers over time, not just in the raw numbers of how long it's stopping the world.

pron 7y ago
That doesn't change the fact that Go's GC is a simplified CMS. It is true that Go does have an easier life -- Java does do escape analysis and allocates on the stack, but it doesn't have value types just yet, and so the allocation rates are higher, which is why Java is not drastically faster. I.e. a cruder GC that's similar to OpenJDK's GC from two generations ago works OK for Go. Despite Go having an easier life, Java 14 performs noticeably better than Go, partly due to having a better compiler, but also because its GCs are just better.