6 ms·

Improving G1 out-of-the-box performance

76 points by arunc 7y ago

bitcharmer 7y ago
Great to see progress in this space. I remember trying out G1 for the first time years ago and almost immediately noping out of it as the performance was terrible. Working in low-latency space the angle for me is much more about GC latency (in microsecond-level scales). I've never seen anyone doing a thorough evaluation of GC times across different implementations. Does anyone here have any interesting sources to share?
- noelwelsh 6y ago
  I haven't spent much time in the world of JVM tuning, but if latency is your main concern the relatively new ZGC should be your jam: https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main
  - pron 6y ago
    Yep. ZGC will soon offer worst-case pauses of <1ms (it's around 2-3 now).
    - The_rationalist 6y ago
      For how much % less of throughput tough?
      - pron 6y ago
        You can take a look at the slides and talks here: https://wiki.openjdk.java.net/display/zgc/ https://wiki.openjdk.java.net/display/zgc/
        The_rationalist 6y ago
        Thanks! Nice to know they added support for class data sharing in jvm 15!
    - maxpert 6y ago
      Is ZGC production ready? Specially with JVM11?
      - noelwelsh 6y ago
        I haven't used it myself but I have heard others do so with success. It looks like JDK14 has some significant improvements to ZGC so I would try to run on that if possible. I might do some performance tests of my own soon.
      - pron 6y ago
        It will be declared non-experimental in 15, but people are running it in production on 14. GCs, and performance in general, tend to improve quite significantly between releases.
        MaxBarraclough 6y ago
        Great news. How about the rival Shenandoah GC?
        pron 6y ago
        They're both non-experimental in 15: https://openjdk.java.net/projects/jdk/15/ https://openjdk.java.net/projects/jdk/15/
    - bitcharmer 6y ago
      This is interesting; I would really appreciate source on this. Also, what are the parameters for this assessment (cpu count, cpu frequency, memory frequency, heap size, object demography etc)?
      - pron 6y ago
        There's material here (talks, slides etc.): https://wiki.openjdk.java.net/display/zgc/ https://wiki.openjdk.java.net/display/zgc/ I think the plan is to reach the 1ms worst-case goal in 15 or 16.
blattimwind 6y ago
> The effect is that out of the box a 1 MB region size will be used, while for the fixed heap case the region size will be 2 MB. It might sound like a small difference, but the benchmark uses a significant amount of large objects that need special treatment when using 1 MB regions. This special treatment leads to a lot of memory that can’t be used, which in turn leads full collections and a poor overall experience. This means the same problem as before can be observed, you'll just need slightly bigger objects to get there.
- winkeltripel 6y ago
  That's what I thought too. perhaps this should be profiled and adjusted on-the-fly (probably a massive undertaking)?
  - ashtonkem 6y ago
    The Java way is more about selecting a reasonable default, and then exposing a tuning parameter for those whose use case falls well off of what was designed for.
joosters 6y ago
Is it just me, or does all garbage collector development seem to go through an endless loop of: * We've optimised this release for throughput * We've optimised this release for latency * We've optimised this release for minimising memory usage ...and each release causes a regression in the stuff they weren't optimising for, leading to another future release picking one of the other three targets. Java and Go seem to have gone round this cycle more than once...
- eklavya 6y ago
  Yeah, but the baseline improves every time. GCs have come a long way in performance, don't you think?
- geodel 6y ago
  One important difference between Java and Go is that Java prides itself in having at least half dozen GC implementations and endless array of tuning parameters. So each factor you listed can be tuned at any time and not part of particular released version. Whereas for Go memory usage is more or less same in almost every release. They have singular focus on latency improvement in general or very specific type of workloads with each new release.
- deleted 6y ago
  [deleted]
- ashtonkem 6y ago
  My suspicion is that these correspond with changes in how these languages are used. I believe (but can’t prove) that Java has been shifting more from a batch processing language to a web services language. In the former throughput is king, in the latter latency is more important. Also, the cost of memory keeps dropping, especially with auto scaling cloud services, which makes optimizing for memory footprint an increasingly bad idea.
- nvarsj 6y 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.
genpfault 6y ago
Not that[1] G1. [1]: https://en.wikipedia.org/wiki/HTC_Dream https://en.wikipedia.org/wiki/HTC_Dream

76 points by arunc 7y ago

Great to see progress in this space. I remember trying out G1 for the first time years ago and almost immediately noping out of it as the performance was terrible. Working in low-latency space the angle for me is much more about GC latency (in microsecond-level scales). I've never seen anyone doing a thorough evaluation of GC times across different implementations. Does anyone here have any interesting sources to share?

noelwelsh 6y ago
I haven't spent much time in the world of JVM tuning, but if latency is your main concern the relatively new ZGC should be your jam: https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main
- pron 6y ago
  Yep. ZGC will soon offer worst-case pauses of <1ms (it's around 2-3 now).
  - The_rationalist 6y ago
    For how much % less of throughput tough?
    - pron 6y ago
      You can take a look at the slides and talks here: https://wiki.openjdk.java.net/display/zgc/ https://wiki.openjdk.java.net/display/zgc/
      - The_rationalist 6y ago
        Thanks! Nice to know they added support for class data sharing in jvm 15!
  - maxpert 6y ago
    Is ZGC production ready? Specially with JVM11?
    - noelwelsh 6y ago
      I haven't used it myself but I have heard others do so with success. It looks like JDK14 has some significant improvements to ZGC so I would try to run on that if possible. I might do some performance tests of my own soon.
    - pron 6y ago
      It will be declared non-experimental in 15, but people are running it in production on 14. GCs, and performance in general, tend to improve quite significantly between releases.
      - MaxBarraclough 6y ago
        Great news. How about the rival Shenandoah GC?
        pron 6y ago
        They're both non-experimental in 15: https://openjdk.java.net/projects/jdk/15/ https://openjdk.java.net/projects/jdk/15/
  - bitcharmer 6y ago
    This is interesting; I would really appreciate source on this. Also, what are the parameters for this assessment (cpu count, cpu frequency, memory frequency, heap size, object demography etc)?
    - pron 6y ago
      There's material here (talks, slides etc.): https://wiki.openjdk.java.net/display/zgc/ https://wiki.openjdk.java.net/display/zgc/ I think the plan is to reach the 1ms worst-case goal in 15 or 16.

blattimwind 6y ago

> The effect is that out of the box a 1 MB region size will be used, while for the fixed heap case the region size will be 2 MB. It might sound like a small difference, but the benchmark uses a significant amount of large objects that need special treatment when using 1 MB regions. This special treatment leads to a lot of memory that can’t be used, which in turn leads full collections and a poor overall experience. This means the same problem as before can be observed, you'll just need slightly bigger objects to get there.

winkeltripel 6y ago
That's what I thought too. perhaps this should be profiled and adjusted on-the-fly (probably a massive undertaking)?
- ashtonkem 6y ago
  The Java way is more about selecting a reasonable default, and then exposing a tuning parameter for those whose use case falls well off of what was designed for.

joosters 6y ago

Is it just me, or does all garbage collector development seem to go through an endless loop of: * We've optimised this release for throughput * We've optimised this release for latency * We've optimised this release for minimising memory usage ...and each release causes a regression in the stuff they weren't optimising for, leading to another future release picking one of the other three targets. Java and Go seem to have gone round this cycle more than once...

eklavya 6y ago
Yeah, but the baseline improves every time. GCs have come a long way in performance, don't you think?
geodel 6y ago
One important difference between Java and Go is that Java prides itself in having at least half dozen GC implementations and endless array of tuning parameters. So each factor you listed can be tuned at any time and not part of particular released version. Whereas for Go memory usage is more or less same in almost every release. They have singular focus on latency improvement in general or very specific type of workloads with each new release.
deleted 6y ago
[deleted]
ashtonkem 6y ago
My suspicion is that these correspond with changes in how these languages are used. I believe (but can’t prove) that Java has been shifting more from a batch processing language to a web services language. In the former throughput is king, in the latter latency is more important. Also, the cost of memory keeps dropping, especially with auto scaling cloud services, which makes optimizing for memory footprint an increasingly bad idea.
nvarsj 6y 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.

genpfault 6y ago

Not that[1] G1. [1]: https://en.wikipedia.org/wiki/HTC_Dream https://en.wikipedia.org/wiki/HTC_Dream