5 ms·

ZGC: A Scalable Low-Latency Garbage Collector [video]

67 points by javinpaul 8y ago

bradleyjg 8y ago
The talk has a lot of interesting technical details, but the bottom line for java developers or jvm sys admins is that the new GC trades off throughput for reduced maximum pause times (current goal is 10ms max pause time, longer term goal is less than 1 ms). The upshot of that is that you probably don't want to swap to this unless you use a relatively large heap (at least 32 GB, maybe more), because below that level the STW latency of the other GC options aren't generally speaking bad enough to be worth the trade-off. Also if latency is a big concern for you and you've got dollars to spend consider Azul zing as well. (That part isn’t from the talk.)
- gbasin 8y ago
  Yep, this. Although to be fair, Zing is pretty good but not a panacea. It causes latencies to increase across the board -- probably due to increased allocation times, or maybe messing with the cache
  - chrisseaton 8y ago
    > probably due to increased allocation times Doesn’t C4 still use a thread-local bump allocator? How does that increase allocation time? I would think it’s much more likely to be the complex barriers.
    - gbasin 8y ago
      Yes you're probably right. I haven't dug much into it myself
      - giltene 8y ago
        If you did (dig into it yourself), you'd quickly find out that the urban myth about Zing somehow hurting latencies across the board is plain wrong. In fact, these days it tends to be percievably faster (in both latency and throughput) in about 70-80% of the workload we encounter. Certainly when compared to G1GC and CMS, and often even when compared to ParallelGC... E.g. it is typicaly >10% faster at things like Cassandra, Spark (TPC-DS), LMAX Disruptor workloads, etc. etc. etc.
geodel 8y ago
I expect Rust's resident GC expert enlighten people working on ZGC why their approach is wrong in trading throughput for low latency. And that they need to learn from hotspot GC.
- jganetsk 8y ago
  Rust doesn't have GC.
  - sitkack 8y ago
    Not in this universe.
  - dpc_pw 8y ago
    Sure we do: https://boats.gitlab.io/blog/post/shifgrethor-iii/ https://boats.gitlab.io/blog/post/shifgrethor-iii/ ;)
  - weberc2 8y ago
    Rust has a static GC https://words.steveklabnik.com/borrow-checking-escape-analysis-and-the-generational-hypothesis https://words.steveklabnik.com/borrow-checking-escape-analys... :)
- solarkraft 8y ago
  Rust GC?
- steveklabnik 8y ago
  https://news.ycombinator.com/item?id=18144169 https://news.ycombinator.com/item?id=18144169
- weberc2 8y ago
  I agree his posts were tiresome, but it's one thing to respond to such a post and quite another to drudge up the issue appropos of nothing. :(
- fmstephe 8y ago
  https://news.ycombinator.com/item?id=14379636 https://news.ycombinator.com/item?id=14379636 I assume this relates to this conversation? This is a bit of a snippet from a broader discussion (which I found really interesting). Maybe there were other discussions here about GC that I missed. I would like to respond here, not because I want to continue some heated debate, but because questions of garbage collectors and the _many_ decisions and trade-offs available are very interesting. And they deserve a good treatment. I don't think it's really fair to characterise pcwalton's position in this way. I think that his comments on Go's GC were quite reasonable and well informed. Go (which I think (and maybe mistakenly) is the real subject of the parent comment) _does_ have a very innefficient GC right now. But that could be changing in a near-future. Some people are experimenting with adding generations to Go garbage collector. It's not clear how long this will take to accomplish. In addition to the problem of 'building a generational GC that is low latency' there are lots of parts of the runtime which currently rely on memory allocations not moving. So there's a lot of ordinary engineering work to be done to ensure that _everything_ works with a generational GC. So in this respect Go may soon 'learn from hotspot'. In order to avoid anyone thinking that I am anti-Go. I am a full time Go programmer. I really like Go, and I think the decision to prioritise latency over throughput was the right choice. But, there is a lot that can be improved in the current GC. I spend a fair bit of my time trying to manage it during they day. Anyway, it feels a bit sad to see this super super fun topic turn into some kind of grudge. If pcwalton has thoughts on ZGC I would be keen to hear them.
nickpsecurity 8y ago
Slides for folks that don't want to watch a video: https://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf https://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.p...
rayiner 8y ago
It's interesting that the conditional read barrier is so cheap (4% overhead on SPECjbb). In past work, read barriers have been considered relatively high overhead and thus algorithms dependent on them avoided for that reason. For example: https://hosking.github.io/links/Yang+2012ISMM.pdf https://hosking.github.io/links/Yang+2012ISMM.pdf (see Table 3 on page 41).
- giltene 8y ago
  It is an LVB (a Loaded [reference] Value Barrier), as documented and fully descibed in https://www.azul.com/files/c4_paper_acm.pdf https://www.azul.com/files/c4_paper_acm.pdf. The Mark/Compact GC algorithm used by ZGC (see section 2 in the paper) and the LVB barrier that powers it in the ZGC implementation are identical to the ones C4 uses in each of its generations, including the details of barrier invariants and guanatees, self healing, use of (non-addressing) metadata information in references, and even the collector phase behavior down to the mark/remap overlap are all the same. As expalined in the paper, the self-healing nature of the LVB (first described and implemented in https://www.usenix.org/legacy/events/vee05/full_papers/p46-click.pdf https://www.usenix.org/legacy/events/vee05/full_papers/p46-c...) makes its actual dynamic cost several orders of magnitude smaller (e.g. during lengthy concurrent GC cycles) than that of prior read barrier approaches (which tend to have a "hot slow path" during long periods of GC cycle execution), making LVB quite practical for use in high throughoput collector implementations.
- pron 8y ago
  BTW, it's not a read barrier but a load barrier. It's not encountered every time when reading an object field, but only when reading object reference that's stored on the heap (i.e. loading it into a register).
  - rayiner 8y ago
    Isn’t that the traditional definition of a read barrier? E.g. a Baker read barrier is triggered when a field of object reference type is loaded from a heap object. It checks if the loaded pointer is in from space, and if so forwards the object.

67 points by javinpaul 8y ago

The talk has a lot of interesting technical details, but the bottom line for java developers or jvm sys admins is that the new GC trades off throughput for reduced maximum pause times (current goal is 10ms max pause time, longer term goal is less than 1 ms). The upshot of that is that you probably don't want to swap to this unless you use a relatively large heap (at least 32 GB, maybe more), because below that level the STW latency of the other GC options aren't generally speaking bad enough to be worth the trade-off. Also if latency is a big concern for you and you've got dollars to spend consider Azul zing as well. (That part isn’t from the talk.)

gbasin 8y ago
Yep, this. Although to be fair, Zing is pretty good but not a panacea. It causes latencies to increase across the board -- probably due to increased allocation times, or maybe messing with the cache
- chrisseaton 8y ago
  > probably due to increased allocation times Doesn’t C4 still use a thread-local bump allocator? How does that increase allocation time? I would think it’s much more likely to be the complex barriers.
  - gbasin 8y ago
    Yes you're probably right. I haven't dug much into it myself
    - giltene 8y ago
      If you did (dig into it yourself), you'd quickly find out that the urban myth about Zing somehow hurting latencies across the board is plain wrong. In fact, these days it tends to be percievably faster (in both latency and throughput) in about 70-80% of the workload we encounter. Certainly when compared to G1GC and CMS, and often even when compared to ParallelGC... E.g. it is typicaly >10% faster at things like Cassandra, Spark (TPC-DS), LMAX Disruptor workloads, etc. etc. etc.

geodel 8y ago

I expect Rust's resident GC expert enlighten people working on ZGC why their approach is wrong in trading throughput for low latency. And that they need to learn from hotspot GC.

jganetsk 8y ago
Rust doesn't have GC.
- sitkack 8y ago
  Not in this universe.
- dpc_pw 8y ago
  Sure we do: https://boats.gitlab.io/blog/post/shifgrethor-iii/ https://boats.gitlab.io/blog/post/shifgrethor-iii/ ;)
- weberc2 8y ago
  Rust has a static GC https://words.steveklabnik.com/borrow-checking-escape-analysis-and-the-generational-hypothesis https://words.steveklabnik.com/borrow-checking-escape-analys... :)
solarkraft 8y ago
Rust GC?
steveklabnik 8y ago
https://news.ycombinator.com/item?id=18144169 https://news.ycombinator.com/item?id=18144169
weberc2 8y ago
I agree his posts were tiresome, but it's one thing to respond to such a post and quite another to drudge up the issue appropos of nothing. :(
fmstephe 8y ago
https://news.ycombinator.com/item?id=14379636 https://news.ycombinator.com/item?id=14379636 I assume this relates to this conversation? This is a bit of a snippet from a broader discussion (which I found really interesting). Maybe there were other discussions here about GC that I missed. I would like to respond here, not because I want to continue some heated debate, but because questions of garbage collectors and the _many_ decisions and trade-offs available are very interesting. And they deserve a good treatment. I don't think it's really fair to characterise pcwalton's position in this way. I think that his comments on Go's GC were quite reasonable and well informed. Go (which I think (and maybe mistakenly) is the real subject of the parent comment) _does_ have a very innefficient GC right now. But that could be changing in a near-future. Some people are experimenting with adding generations to Go garbage collector. It's not clear how long this will take to accomplish. In addition to the problem of 'building a generational GC that is low latency' there are lots of parts of the runtime which currently rely on memory allocations not moving. So there's a lot of ordinary engineering work to be done to ensure that _everything_ works with a generational GC. So in this respect Go may soon 'learn from hotspot'. In order to avoid anyone thinking that I am anti-Go. I am a full time Go programmer. I really like Go, and I think the decision to prioritise latency over throughput was the right choice. But, there is a lot that can be improved in the current GC. I spend a fair bit of my time trying to manage it during they day. Anyway, it feels a bit sad to see this super super fun topic turn into some kind of grudge. If pcwalton has thoughts on ZGC I would be keen to hear them.

nickpsecurity 8y ago

Slides for folks that don't want to watch a video: https://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf https://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.p...

rayiner 8y ago

It's interesting that the conditional read barrier is so cheap (4% overhead on SPECjbb). In past work, read barriers have been considered relatively high overhead and thus algorithms dependent on them avoided for that reason. For example: https://hosking.github.io/links/Yang+2012ISMM.pdf https://hosking.github.io/links/Yang+2012ISMM.pdf (see Table 3 on page 41).

giltene 8y ago
It is an LVB (a Loaded [reference] Value Barrier), as documented and fully descibed in https://www.azul.com/files/c4_paper_acm.pdf https://www.azul.com/files/c4_paper_acm.pdf. The Mark/Compact GC algorithm used by ZGC (see section 2 in the paper) and the LVB barrier that powers it in the ZGC implementation are identical to the ones C4 uses in each of its generations, including the details of barrier invariants and guanatees, self healing, use of (non-addressing) metadata information in references, and even the collector phase behavior down to the mark/remap overlap are all the same. As expalined in the paper, the self-healing nature of the LVB (first described and implemented in https://www.usenix.org/legacy/events/vee05/full_papers/p46-click.pdf https://www.usenix.org/legacy/events/vee05/full_papers/p46-c...) makes its actual dynamic cost several orders of magnitude smaller (e.g. during lengthy concurrent GC cycles) than that of prior read barrier approaches (which tend to have a "hot slow path" during long periods of GC cycle execution), making LVB quite practical for use in high throughoput collector implementations.
pron 8y ago
BTW, it's not a read barrier but a load barrier. It's not encountered every time when reading an object field, but only when reading object reference that's stored on the heap (i.e. loading it into a register).
- rayiner 8y ago
  Isn’t that the traditional definition of a read barrier? E.g. a Baker read barrier is triggered when a field of object reference type is loaded from a heap object. It checks if the loaded pointer is in from space, and if so forwards the object.