3 ms·

Thanks. Since most of the explanations that you gave involve things like controlling value types and data layout, it sounds to me like you might agree with the

• pcwalton 7y ago
  In this case, "tuning for latency over throughput" means "not having a generational GC". Whether this choice makes sense does not depend on how much a program allocates. Rather, it depends on whether the generational hypothesis holds. The generational hypothesis is one of the most powerful and consistent observations in the entire CS field. It certainly holds for .NET, which has a very similar memory model to that of Go, and therefore .NET has a generational garbage collector.
  • mappu 7y ago
    It's not as simple as does the generational hypothesis hold, there are real downsides to having a generational GC - it means you need a copying collector. Go heap values never move, which dramatically simplifies everything else (e.g. other threads don't need to be paused to update heap pointers, reducing STW times). Some previous discussion https://news.ycombinator.com/item?id=17551012 https://news.ycombinator.com/item?id=17551012
    • pcwalton 7y ago
      You don't need stop-the-world pauses for generational GC. As long as your write barrier ensures that pointers to a young object are entirely local to the TLAB that the object is allocated in, you will never need to stop other threads to sweep the nursery.