5 ms·

I don't really see that cycle. I think Hotspot's latency and memory usage has always been atrocious, and they have slowly been working to improve that with Para

by nvarsj 7y ago

I don't really see that cycle. I think Hotspot's latency and memory usage has always been atrocious, and they have slowly been working to improve that with ParallelGC->CMS->G1. I don't think there is a black/white world like Hotspot people tend to claim about these things. You can have your cake and eat it - acceptable latency <10ms/1ms AND good throughput/memory usage is possible without excessive manual tuning. golang is an example of this, as are GCs in other language runtimes. In every other managed language I've worked in, I never even think about the GC 99% of the time. Whereas with Hotspot you have to tune and think about it 100% of the time. Hopefully it will get there one day and make working on JVM projects less painful.

pron 7y ago
Go's GC's throughput is significantly lower than that of all OpenJDK's GCs, and its latency numbers are misleading because they don't account for throttling. To give you an example, a GC that works as follows -- allocate by pointer bumping from a thread-local buffer, and when it runs out, freeze the thread forever -- would count as having zero latency according to Go's metrics, because this infinite pause is per-thread rather than stop-the-world; of course, the throughput will eventually drop to zero, too, but they don't report throughput. Why, then, do you see Go applications performing more-or-less OK? Because of two things: they allocate fewer objects, and they just run significantly more slowly than Java, except this slowdown is paced. In terms of algorithm, Go's GC is pretty-much a simplified version (no young generation) of OpenJDK's now-defunct CMS plus throttling. G1 is a generation beyond that, and ZGC is two.
- Scaevolus 7y ago
  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.

by nvarsj 7y ago

pron 7y ago

Go's GC's throughput is significantly lower than that of all OpenJDK's GCs, and its latency numbers are misleading because they don't account for throttling. To give you an example, a GC that works as follows -- allocate by pointer bumping from a thread-local buffer, and when it runs out, freeze the thread forever -- would count as having zero latency according to Go's metrics, because this infinite pause is per-thread rather than stop-the-world; of course, the throughput will eventually drop to zero, too, but they don't report throughput. Why, then, do you see Go applications performing more-or-less OK? Because of two things: they allocate fewer objects, and they just run significantly more slowly than Java, except this slowdown is paced. In terms of algorithm, Go's GC is pretty-much a simplified version (no young generation) of OpenJDK's now-defunct CMS plus throttling. G1 is a generation beyond that, and ZGC is two.

Scaevolus 7y ago
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.