Hacker News Reader

Comment by _ak | Hacker News Reader

40 ms mutator time per 50 ms time window. That means that your program will never be interrupted for longer than 10 ms within 50 ms.

In practice, the STW mark and sweep phases are in the sub-millisecond range, and the GC runs not nearly as often as 20 times a second, so 10 ms of interruptions per 50 ms is the absolute worst case.

View on HN

I think these are goals, not guarantees, and the numbers are predicated on assumptions about extra free memory available to the GC.

There is an inherent tradeoff between pauses, throughput and extra memory requirements.

Well, the latency is capped at 10 ms, the STW phases will stop at that limit. So that guarantee can be kept as long as your memory allocation throughput is low enough so as not to trigger a GC run more than 20 times a second. Which is pretty good. There aren't that many GC implementations in production that will give you a guarantee of the same or similar quality.

Can you point me to an authoritative source that explains what exactly is guaranteed under what assumptions and what is done on a best effort basis only?

The authoritative source is the Go source code. Read it, it's relatively easy to understand, and fairly obvious that the STW mark termination phase goroutine (like any other goroutine) will be preempted after forcePreemptNS (which is 10ms), and if that happens even though it hasn't finished its work, it transitions to a concurrent task, and resumes later.

If you're interested in the finer details, I'm sure the GC talk at golangUK later this month will discuss them all, and the slides and/or videos will eventually land here on Hacker News.

The goals are also predicated on your OS configuration and having a zero load average.

Reply on news.ycombinator.com