Thread

A 40ms Go garbage collector pause caused by swap

48 points · 11 comments · shellpipe

Loading the complete thread in the background. This saved snapshot is available now. Refresh

octoberfranklin · 1791174654 · focus · HN ↗
Yet another reason why "no runtime" is such a huge advantage.
1. my-next-account · 1791178801 · focus · HN ↗
  You're probably coding for a 'runtime' in the broad sense: libc and your kernel.
pizlonator · 1791174664 · focus · HN ↗
Is there a reason why Go isn’t using on the fly GC, where there’s no STW at all?
1. klodolph · 1791175284 · focus · HN ↗
  What I found when I searched for "on the fly" is this: <a href="https://github.com/mthom/on-the-fly-gc" rel="nofollow">https://github.com/mthom/on-the-fly-gc — it looks like it has pauses, from the docs.
  In general when you tune knobs for GC, you pay for benefits in one area with sacrifices in another. Two big knobs to turn are pause latency and throughput. You probably wouldn’t want to go full “optimize for latency” because you’d end up with poor throughput. Also vice versa. Java’s reputation for poor GC performance is partly due to historical defaults that tune it for throughput.
  1. pizlonator · 1791176130 · focus · HN ↗
    The classic on the fly GC algorithm is DLG, hilariously published in two papers, because the first one had a bug. Here's the second paper: <a href="https://caml.inria.fr/pub/papers/doligez_gonthier-gc-popl94.pdf" rel="nofollow">https://caml.inria.fr/pub/papers/doligez_gonthier-gc-popl94....
    It's a well known algorithm. Folks who do GCs for a living know about it. The folks who work on Go are surely aware of it. I'm assuming that they do not use it for a good reason, hence my question!
    Fil-C's GC (Fil's Unbelievable Garbage Collector) uses an alternative on-the-fly algorithm, which I call Phil's Concurrent Marking.
    I've documented it here: <a href="https://fil-c.org/fugc" rel="nofollow">https://fil-c.org/fugc
    Here's the source: <a href="https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/libpas/fugc.c" rel="nofollow">https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/l...
    Phil's Concurrent Marking differs from DLG in that it only requires a Djikstra barrier and uses a permagrey stack (something that Go used to do).
    However, FUGC does clever things for coroutines (as in ucontexts, which Fil-C supports) - they are not permagrey; they only become grey if they execute. That's relevant to Go because Go moved away from permagrey stacks because of coroutine scan overheads, which the FUGC coroutine strategy might avoid.
    But even if Go could not go back to permagrey, then the answer would be to use DLG, which would involve using the combined Yuasa+Dijstra barrier, which Go uses today anyway
truth_seeker · 1791174952 · focus · HN ↗
What is stopping the author to use latest version of Go and Linux Kernel ?
soltanov · 1791175840 · focus · HN ↗
A GC latency SLO should include operating-system memory pressure. Otherwise, a page-fault problem will look like a collector problem and lead to the wrong fix.
jacobgold · 1791177892 · focus · HN ↗
"It hurts when I do this"
"Stop doing that"
If you care about latency, disable swap. System wide or for the specific the cgroup.
1. delamon · 1791179707 · focus · HN ↗
  This is not entirely correct. If you care about latency, then it doesn't matter on which major fault your application gets paused. Disabling swap protects you from data pages being evicted, but code pages can still be paged out.
  If you care about latency, mlock() your memory, do not disable swap. Swap is good and gives the kernel an equal opportunity to evict data and code pages.
ahmedmostafa16 · 1791179447 · focus · HN ↗
The nasty bit is that swap doesn't just make the allocation slower; if GC metadata gets paged out, you have turned memory pressure into a stop-the-world latency spike.
raverbashing · 1791179654 · focus · HN ↗
I don't get why people do not prefer reference counting, it has more predictable runtime performance
(though of course a swap is a swap - but you can "trigger" it depending on your memory or file access pattern)

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.