On Fri, Apr 21, 2017 at 5:58 PM st ov <so.qu...@gmail.com> wrote: > @Jesper, curious how you determined that? > Is it in the spec? or the source? > Or is this a common GC pattern that you presume is being used? > > There are a couple of design documents by Clements and Hudson which are worth reading. They are well written, and they do a good job at acknowledging both what problems are solved and what problems are left to solve.
Another source is this very mailing list. You can read what problems people have had and then try to form a hypothesis around it. Finally, I have an acute interest in systems with low-latency soft-realtime properties. Especially when those systems use garbage collectors rather than manual memory management. This can sometimes inform you about typical "pain points" in the system designs. It turns out my initial hypothesis must be rejected however. The gctrace=1 output tells an entirely different story because normal collections are not getting delayed in the mark termination phase, which is what my hypothesis suggested. I cannot stress how important it is to measure. As for understanding the gctrace=1 output, go with the documentation of 'package runtime' rather than older blog posts. It is release-specific and thus likely to change a little bit. Keep this in mind when you read older posts. However, some of the posts by Dave Cheney seems good because they also tell you a bit of background about what to look out for. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
