ZGC: A Scalable Low-Latency Garbage Collector [video] | Hacker News Reader

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

youtube.com

67 pointsjavinpaul22 comments

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.)

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

> 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.

Yes you're probably right. I haven't dug much into it myself

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.

Slides for folks that don't want to watch a video:

https://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.p...

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 (see Table 3 on page 41).

It is an LVB (a Loaded [reference] Value Barrier), as documented and fully descibed in 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-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.

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).

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.

it would be interesting to have a database of small assumptions (Do(S)A) and watch how they evolve over time. Seems like a common theme in innovation is to spot the assumption inversion and make the obvious move.

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.

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.

> 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.

Absolutely agree.

To add a little more context, the frustrations were that his comments were repetitive and the threads didn't go anywhere and generally distracted from more productive conversations. Minor nuissance, and it's been a while since he's posted more of those comments (at least I haven't seen them in a while), so we should get off his back (not all of my comments have been solid gold either). He's a knowledgable person and has a lot to offer me and this community generally.

Hopefully we can all move past this and be a little more gracious and tactful with each other, because you're right--this is a really interesting, fun topic.

Great :)

Rust doesn't have GC.

Rust has a static GC

https://words.steveklabnik.com/borrow-checking-escape-analys...

Sure we do: https://boats.gitlab.io/blog/post/shifgrethor-iii/ ;)

Not in this universe.

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. :(

https://news.ycombinator.com/item?id=18144169

Rust GC?

Reply on news.ycombinator.com