4 ms·
Do you even know Go's GC guarantees?
by _ak 10y ago
Do you even know Go's GC guarantees?
- millstone 10y agoI don't! What are they?
- _ak 10y ago40 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.
- fauigerzigerk 10y agoI 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.