3 ms·
Java 7 and above provide XX:MaxGCPauseMillis flag for GC conf From Mechanical Sympathy Blog [1] " G1 is target driven on latency –XX:MaxGCPauseMillis=<n>, de
by geodel 10y ago
Java 7 and above provide XX:MaxGCPauseMillis flag for GC conf
From Mechanical Sympathy Blog [1]
" G1 is target driven on latency –XX:MaxGCPauseMillis=<n>, default value = 200ms. The target will influence the amount of work done on each cycle on a best-efforts only basis. Setting targets in tens of milliseconds is mostly futile, and as of this writing targeting tens of milliseconds has not been a focus of G1. "
So in Java world we are talking 100s of milli seconds of worst case which is 3 order of magnitude higher than Go.
1. http://mechanical-sympathy.blogspot.com/2013/07/java-garbage-collection-distilled.html http://mechanical-sympathy.blogspot.com/2013/07/java-garbage...
- pcwalton 10y agoWell, yeah. You're comparing the G1 (for server workloads) to Go's concurrent collector. There's a concurrent collector you can use in incremental mode for the JVM if you want to trade throughput for pause time, like Go does. The HotSpot designers have (correctly, IMO) observed that server use cases typically prefer throughput to latency. On a meta note, I wish people would focus on the actual algorithms instead of taking cited performance numbers out of context and comparing them head to head. The Go GC uses the same concurrent marking and sweeping techniques that CMS does. This change to avoid stop the world stack sweeps is something that no HotSpot collector does. But it's counterbalanced by the fact that Go's GC is not generational. Generational GCs change the balance significantly by dramatically improving throughput.
- sambe 10y agoIn my experience you are still getting single-to-double-digit millisecond pauses on average using CMS (even with some attention/tuning). Do you really think Hotspot can offer a GC where pauses longer than 100us are considered interesting enough to look into?
- pcwalton 10y agoSure, if they implement barriers for stack references like Go is. But that's a significant throughput hit.
- sambe 10y agoMy original intention was to ask if you think that's currently achievable. But also interesting for the future.
- zigzigzag 10y agoWell, probably not. The question is what use cases can tolerate large throughput hits but not few msec pause times (G1 can also do pauses of a few msec in many cases, I see hundred msec pause times on very large heaps, but not desktop sized heaps). I suspect there are very few use cases. The G1 team seems to be focusing on scaling to ever larger heaps right now, like hundreds of gigabytes in size. They're relatively uninterested in driving down pause times as Shenandoah is going to provide that for the open source world and Azul already does for the $$$ world.
- geodel 10y agoUnless you have numbers to share for CMS latency in Java I have no reason to assume that they are materially different from G1. I am using CMS for my server applications and multi second latency is quite common STW pauses in CMS. In general Oracle JDK uses order of magnitude more memory and order magnitudes higher GC latency compare to Go. IMO it is quite useful to remember when deciding on language on new projects. If hotspot people think that these numbers are not true I am sure they would let people know.
- the8472 10y ago* Heap size and stack sizes × number of threads matters. JVMs can manage hundreds of OS threads with deep stacks and 100GB+ heaps. * Go's GC is completely non-compacting while G1 is for all generations and CMS for all but the old generation. * Shenandoah will offer lower pause times by doing concurrent compacting, at the expense of throughput. * Azul already offers a pauseless compacting collector for hotspot
- geodel 10y agoHere are Shenandoah pause numbers 11]. Max pause is 45ms which I would agree is ultra low pause for Java. Because 100s of ms pause is common for by Java server applications. Here are GC numbers for Go >= 1.6 for 100GB+ [2]. Go 1.7/1.8 have/going to have lower numbers than that. 1. http://www.slideshare.net/RedHatDevelopers/shenandoah-gc-java-without-the-garbage-collection-hiccups-christine-flood http://www.slideshare.net/RedHatDevelopers/shenandoah-gc-jav... 2. https://talks.golang.org/2016/state-of-go.slide#37 https://talks.golang.org/2016/state-of-go.slide#37
- the8472 10y agoA big difference is that Shenandoah still does compacting while gogc does not. That also means it can do bump-pointer allocation, i.e. it has a faster allocation path.
- geodel 10y agoThere must be some end user (positive) impact of memory compaction in Java. But I do not see in benchmarks where Java programs takes 2-10 times more memory and runs slower than Go. http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html
- the8472 10y agoThose benchmarks are of limited use since the JVM has startup costs which get armortized over time. Full performance is only achieved after JIT warmup. AOT would improve that, but on openjdk that's experimental and few people use other JVMs that support AOT out of the box. About the memory footprint: The runtime is larger, so there's a baseline cost you have to pay for the JITs. But baseline != linear cost. If you have a long-running applications that run more than a few seconds and crunch more than a few MB of data those numbers would change. So unless you're using the JVM for one-shot script execution those benchmarks are not representative. And if you do then there would be certain optimizations that one could apply. > There must be some end user (positive) impact of memory compaction in Java. Fewer CPU cycles overhead per unit of work, i.e. better throughput, which does seem to be an issue for gogc[0]. No risk of quasi-leaks in the allocator due to fragmentation. Reduced cache misses[1] [0] https://github.com/golang/go/issues/14161 https://github.com/golang/go/issues/14161 [1] http://stackoverflow.com/q/31225252/1362755 http://stackoverflow.com/q/31225252/1362755