On Mon, Dec 19, 2016 at 8:56 PM, Tyler Compton <xavi...@gmail.com> wrote: > https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7 > > Thoughts? How accurate is this article? If it is, why, historically, is the > work being done on the GC so concentrated on pause times?
If you click on the comments link near the bottom you will see that Rick has commented on part of the essay. I do not work on the GC myself, but these are my personal observations. I think the key observation in Go's GC is that modern systems have multiple cores, and are rapidly getting more cores. Throwing more cores at the problem is a sensible approach on modern hardware. Since the cores are no longer getting faster, making your code run faster on a single core is not the optimal design for the hardware of the near future. For a language like Go, stop-the-world pause times really are the most important thing, because during a pause your server isn't doing anything useful. The essay suggests that the Go runtime is "willing to slow down your program by almost any amount" in order to reduce pause times; that is clearly hyperbole, and it isn't literally true. The slowdowns in compiled Go code occur when writing pointers into the heap and when allocating new memory. The compiler works hard to let you store variables on the stack rather than the heap, where no slowdown occurs. The language is designed to let you control when and how memory is allocated, giving you control over when memory is allocated. The effect is that in Go you can adjust your program to reduce GC overhead, rather than tuning the GC. This is far more true in Go than in Java, since Java has no stack variables or structs. I'm not familiar enough with C# to say anything serious about it. That said, it should be obvious that nobody thinks that work on Go's garbage collector has finished. The essay mentions the request-oriented collector, which is indeed similar to a generational garbage collector. If everything works, the request oriented collector can be cheaper than a generational collector because no copying is required. The essay suggests that it can be simulated by a generational GC "by ensuring the young generation is large enough that all garbage generated by handling a request fits within it" but that is somewhat meaningless if any of your requests can use a lot of memory, since you have to waste a lot of space by allocating that much memory for each goroutine. Once the request-oriented collector is working or abandoned, I believe the GC team plans to focus on increasing throughput, since latency is now low enough that it hopefully doesn't matter for non-realtime programs. Ian -- 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.
