Theme 1 – Swap / page‑file pressure creates stop‑world GC pauses
- “If you care about latency, disable swap.” – jacobgold
- “Disabling swap … just moves the pressure elsewhere: the kernel will page out code and your app gets paused whenever the execution flow hits such a page.” – delamon
- “If GC metadata gets paged out, you have turned memory pressure into a stop‑the‑world latency spike.” – ahmedmostafa16
- “Swap latency explodes when you get into a swap storm … forming a queue waiting for swap IO.” – the8472
Theme 2 – GC algorithm trade‑offs (latency vs. throughput, on‑the‑fly, reference counting)
- “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.” – klodolph
- “Go’s GC is already a ‘concurrent mark‑sweep garbage collector’ and already has ‘extremely low mutator pause times, on the order of tens of microseconds’.” – klodolph
- “The classic on the fly GC algorithm is DLG… Folks who do GCs for a living know about it.” – pizlonator
- “Reference counting can cause a single object deallocation to trigger an arbitrarily long chain of deallocations.” – bheadmaster
- “Reference counting is expensive in multi‑threaded applications.” – xxs
- “Reference counting is promising … it meshes well with static analysis … could optimise away RC altogether.” – Findecanor
Theme 3 – Mitigations and alternatives (mlock, OS‑GC cooperation, less garbage, language choice)
- “If you care about latency, mlock() your memory, do not disable swap.” – delamon
- “You could MADV_WILLNEED the GC metadata when you start the GC process hoping they’ll have been paged in by the time you STW.” – masklinn
- “The OS should also allow marking pages as priority to stop them from being swapped out.” – aktau / torginus
- “If you have a garbage collection problem my first intuition would be to produce less garbage!” – Someone / iamvik
- “I use Rust where i need low latency.” – faangguyindia