3 ms·
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 tradeo
by fauigerzigerk 10y ago
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.
- _ak 10y agoWell, 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.
- fauigerzigerk 10y agoCan 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?
- _ak 10y agoThe 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.
- madgar 10y agoThe goals are also predicated on your OS configuration and having a zero load average.