4 ms·
[I work on Go.] As you say, the pacing strategy is about delivering good performance, not about pause times. Pause times are a separable concern. The current
by rsc 12y ago
[I work on Go.]
As you say, the pacing strategy is about delivering good performance, not about pause times. Pause times are a separable concern.
The current (in development) GC is not pauseless. It stops the world to finish each collection. Those pauses are very short (well under 10ms, often under 1ms) so we are not worrying about eliminating them at the moment. But we know how to do that if we choose to.
http://dl.acm.org/citation.cfm?id=376810 http://dl.acm.org/citation.cfm?id=376810 (Sapphire) is the current state of the art for pauseless collectors, and one of the authors is the primary developer working on the Go GC now.
As a side note, if you don't compact then pauseless becomes much easier. And while it was taken as gospel for decades, it's not clear that on today's hardware you necessarily need to compact, ever. (Cue flames.)
- tomp 12y ago> And while it was taken as gospel for decades, it's not clear that on today's hardware you necessarily need to compact, ever. (Cue flames.) Yeah, my (theoretical) designs skipped compaction as well. I would have different arenas for differently-sized objects instead (akin to e.g. TCMalloc), which could be reused very efficiently (although that's probably a common allocation technique by now). Although you could still grow a huge heap in very specific situations, if the program behaved at least somewhat consistently (kept allocating objects of roughly the same size), you wouldn't need compaction at all. Again, this is just theory, unfortunately :) I'll check out Sapphire!