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.
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.
3 comments
[ 2.1 ms ] story [ 17.5 ms ] thread