7 ms·

Does anyone have comparable GC latency numbers comparing Go vs Java as of 2018?

nvarsj 8y ago
It’s not even a contest on the latency front. Golang gc targets sub ms, hotspot easily hits 100s of ms. A well tuned hotspot can reach 10s of ms pauses on average, with a long tail of 100 ms+. This is on typical apps.
- pjmlp 8y ago
  Unless one gets to use Azul or real time JDK. It is easy to forget there isn't a single answer with Java.
  - deleted 8y ago
    [deleted]
  - nvarsj 8y ago
    Yeah true, but C4 is a commercial product, and I've yet to meet someone that used it. But on paper, Azul's C4 GC sounds really great. I think it might require a custom kernel as well, and some other OS restrictions - which would also somewhat limit its usage as a general purpose collector.
- pron 8y ago
  1. This is not due to GC design but to language semantics (value types, which aren't yet available in Java). 2. In September '18, ZGC will be available in OpenJDK on Linux/x86 (available today in early access), which also targets sub ms pauses (and guarantees under 10ms): https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main Note that at some point, worst-case latency becomes far less meaningful than throughput, because unless running on a realtime OS, the OS introduces bigger pauses, and it makes no sense for the GC to try and beat them.
  - pjmlp 8y ago
    And even on the real time case, we have then the real time extensions, even though they are out of range for most devs (price wise).
  - ngrilly 8y ago
    > This is not due to GC design but to language semantics (value types, which aren't yet available in Java). The fact that Go has value types helps a lot, but the latency inferior to 0.5 ms is mainly the result of GC design, as explained in the discussed article (especially the work on removing as much as possible stop the world pauses). > Note that at some point, worst-case latency becomes far less meaningful than throughput, because unless running on a realtime OS, the OS introduces bigger pauses, and it makes no sense for the GC to try and beat them. This is already said in the article.
    - pron 8y ago
      Because you usually pay for latency with throughput, you can afford the low latency achieved with a simpler design only if you have less concurrent work.
      - masklinn 8y ago
        Go is not magic, and does in fact pay for latency with throughput: https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/dbe958e/ https://www.reddit.com/r/golang/comments/5j7phw/modern_garba... > Go: 67 ms max, 1062 pauses, 23.6 s total pause, 22 ms mean pause, 91 s total runtime > Java, G1 GC, no tuning: 86 ms max, 65 pauses, 2.7 s total pause, 41 ms mean pause, 20 s total runtime
        nvarsj 8y ago
        I couldn't find the benchmarks for that comment. But the Java numbers seem way off. It must have been a simple toy application, probably with allocations optimized away somewhere - I'd want to see memory allocation rates to see if they are comparable. G1 is usually higher latency than CMS in my experience, too. Try running Cassandra with G1, and see how good your pauses are. Min viable pause time target for G1 is ~200ms (the hotspot default).
mike_hearn 8y ago
There is a discussion from a year ago that compares them here: https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/ https://www.reddit.com/r/golang/comments/5j7phw/modern_garba... Note that latency isn't the only metric that matters! The top comment from that discussion says this: There were tests lately in which Go GC was almost the fastest latency wise. Go was was couple of times faster than Java in mean latency time but it had 1062 pauses comparing to Java G1 GC which had only 65 pauses. Time spent in GC was 23.6s for Go but only 2.7s in Java. There is no free launch, you need to pay for low latency with throughput. More detail from the same guy: "Go: 67 ms max, 1062 pauses, 23.6 s total pause, 22 ms mean pause, 91 s total runtime Java, G1 GC, no tuning: 86 ms max, 65 pauses, 2.7 s total pause, 41 ms mean pause, 20 s total runtime"

It’s not even a contest on the latency front. Golang gc targets sub ms, hotspot easily hits 100s of ms. A well tuned hotspot can reach 10s of ms pauses on average, with a long tail of 100 ms+. This is on typical apps.

pjmlp 8y ago
Unless one gets to use Azul or real time JDK. It is easy to forget there isn't a single answer with Java.
- deleted 8y ago
  [deleted]
- nvarsj 8y ago
  Yeah true, but C4 is a commercial product, and I've yet to meet someone that used it. But on paper, Azul's C4 GC sounds really great. I think it might require a custom kernel as well, and some other OS restrictions - which would also somewhat limit its usage as a general purpose collector.
pron 8y ago
1. This is not due to GC design but to language semantics (value types, which aren't yet available in Java). 2. In September '18, ZGC will be available in OpenJDK on Linux/x86 (available today in early access), which also targets sub ms pauses (and guarantees under 10ms): https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main Note that at some point, worst-case latency becomes far less meaningful than throughput, because unless running on a realtime OS, the OS introduces bigger pauses, and it makes no sense for the GC to try and beat them.
- pjmlp 8y ago
  And even on the real time case, we have then the real time extensions, even though they are out of range for most devs (price wise).
- ngrilly 8y ago
  > This is not due to GC design but to language semantics (value types, which aren't yet available in Java). The fact that Go has value types helps a lot, but the latency inferior to 0.5 ms is mainly the result of GC design, as explained in the discussed article (especially the work on removing as much as possible stop the world pauses). > Note that at some point, worst-case latency becomes far less meaningful than throughput, because unless running on a realtime OS, the OS introduces bigger pauses, and it makes no sense for the GC to try and beat them. This is already said in the article.
  - pron 8y ago
    Because you usually pay for latency with throughput, you can afford the low latency achieved with a simpler design only if you have less concurrent work.
    - masklinn 8y ago
      Go is not magic, and does in fact pay for latency with throughput: https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/dbe958e/ https://www.reddit.com/r/golang/comments/5j7phw/modern_garba... > Go: 67 ms max, 1062 pauses, 23.6 s total pause, 22 ms mean pause, 91 s total runtime > Java, G1 GC, no tuning: 86 ms max, 65 pauses, 2.7 s total pause, 41 ms mean pause, 20 s total runtime
      - nvarsj 8y ago
        I couldn't find the benchmarks for that comment. But the Java numbers seem way off. It must have been a simple toy application, probably with allocations optimized away somewhere - I'd want to see memory allocation rates to see if they are comparable. G1 is usually higher latency than CMS in my experience, too. Try running Cassandra with G1, and see how good your pauses are. Min viable pause time target for G1 is ~200ms (the hotspot default).

mike_hearn 8y ago

There is a discussion from a year ago that compares them here: https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/ https://www.reddit.com/r/golang/comments/5j7phw/modern_garba... Note that latency isn't the only metric that matters! The top comment from that discussion says this: There were tests lately in which Go GC was almost the fastest latency wise. Go was was couple of times faster than Java in mean latency time but it had 1062 pauses comparing to Java G1 GC which had only 65 pauses. Time spent in GC was 23.6s for Go but only 2.7s in Java. There is no free launch, you need to pay for low latency with throughput. More detail from the same guy: "Go: 67 ms max, 1062 pauses, 23.6 s total pause, 22 ms mean pause, 91 s total runtime Java, G1 GC, no tuning: 86 ms max, 65 pauses, 2.7 s total pause, 41 ms mean pause, 20 s total runtime"