3 ms·
FYI, ZGC doesn't perform any collection work in the the stop-the-world pauses. They are only required to get all mutator threads to atomically observe the incre
by pron 3y ago
FYI, ZGC doesn't perform any collection work in the the stop-the-world pauses. They are only required to get all mutator threads to atomically observe the increment of the "GC epoch" for all threads. All actual work, both marking and compaction, is done by GC threads running concurrently with the mutator threads or by the mutator threads themselves as they run. It is only when allocation rate is very, very high that an allocating mutator thread will be paused ("throttled") for a significant amount of time to allow the GC to catch up by freeing up memory (and if you hit these cases, then you might be better off using a throughput-oriented collector).
- hawk_ 3y agoStrangely in our workloads we have noticed generational ZGC latencies are better than G1 at ~99th-99.9th percentile or below but worse at percentiles above that. The allocation rate is moderate.
- kaba0 3y agoAbove that you might easily get measuring artifacts, like the OS swapping out your process once, or so.
- hawk_ 3y agoYes - but it's quite consistent. If it was 'noise' it wouldn't be.
- loeg 3y agoIt can be easy to game metrics like this -- trading off p100 for p99.9 or p99. E.g., defer all the expensive work to 1 in every 10,000 operations.
- znpy 3y ago> FYI, ZGC doesn't perform any collection work in the the stop-the-world pauses. Yeah i know, but on a certain level I don’t care what it does or does not do. I care about my application not having latency spikes due to stop the world pauses :)