A 40ms Go garbage collector pause caused by swap
shellpipe
40 points
11 comments
October 05, 2026
Related Discussions
Found 5 related stories in 79.8ms across 8,480 title embeddings via pgvector HNSW
- Speeding Up the Plush Garbage Collector maxime_cb · 11 pts · August 17, 2026 · 49% similar
- High-performance garbage collection for C++ motownphilly · 29 pts · September 14, 2026 · 45% similar
- Swap, ZRAM, Zswap and Hibernate on NixOS speckx · 58 pts · September 23, 2026 · 43% similar
- Goose:experimental lang 1.16x faster than C++ and 1.12x than safe Rust, mem safe bobbydigitales · 49 pts · September 18, 2026 · 40% similar
- JDK 27 G1/Parallel/Serial GC Changes 0x54MUR41 · 54 pts · August 13, 2026 · 40% similar
Discussion Highlights (7 comments)
octoberfranklin
Yet another reason why "no runtime" is such a huge advantage.
pizlonator
Is there a reason why Go isn’t using on the fly GC, where there’s no STW at all?
truth_seeker
What is stopping the author to use latest version of Go and Linux Kernel ?
soltanov
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
"It hurts when I do this" "Stop doing that" If you care about latency, disable swap. System wide or for the specific the cgroup.
ahmedmostafa16
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
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)