
ZGC: A Scalable Low-Latency Garbage Collector [video] - javinpaul
https://www.youtube.com/watch?v=kF_r3GE3zOo
======
bradleyjg
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
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
> 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
Yes you're probably right. I haven't dug much into it myself

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

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

[https://cr.openjdk.java.net/~pliden/slides/ZGC-
Jfokus-2018.p...](https://cr.openjdk.java.net/~pliden/slides/ZGC-
Jfokus-2018.pdf)

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

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

------
geodel
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
Rust doesn't have GC.

~~~
weberc2
Rust has a static GC

[https://words.steveklabnik.com/borrow-checking-escape-
analys...](https://words.steveklabnik.com/borrow-checking-escape-analysis-and-
the-generational-hypothesis)

:)

