Modern Garbage collection (incl Golang)

[[)roi(]]

An excellent exploration of tradeoffs imposed by tracing Garbage Collectors, covering specifically Java & the Golang implementations. In additional to covering the broader topic of garbage collection, he also explains why the Golang hype about a magic GC, is just hype. There is no magic in Golang's GC; rather just a bunch of compromises that everyone else has typically avoided. It's a long article, but well worth the read for anyone wanting to understand how GCs works; including the complexity balance act.

Personally I prefer ARC, performance, (similar to manual memory management) is always predictable and fairly easy to control.

I’ve seen a bunch of articles lately which promote the Go language’s latest garbage collector in ways that trouble me. Some of these articles come from the Go project itself. They make claims that imply a radical breakthrough in GC technology has occurred.

Here is the initial announcement of a new collector in August 2015:

Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond … Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language. It is a future where applications scale effortlessly along with hardware and as hardware becomes more powerful the GC will not be an impediment to better, more scalable software. It’s a good place to be for the next decade and beyond.

The Go team not only claim to have solved the problem of GC pauses, but also made the entire thing brainless:

At a higher level, one approach to solving performance problems is to add GC knobs, one for each performance issue. The programmer can then turn the knobs in search of appropriate settings for their application. The downside is that after a decade with one or two new knobs each year you end up with the GC Knobs Turner Employment Act. Go is not going down that path. Instead we provide a single knob, called GOGC.
Furthermore, unencumbered by ongoing support for dozens of knobs, the runtime team can focus on improving the runtime based on feedback from real customer applications.

..
As Go is a relatively ordinary imperative language with value types, its memory access patterns are probably comparable to C# where the generational hypothesis certainly holds and thus .NET uses a generational collector.
In fact Go programs are usually request/response processors like HTTP servers, meaning that Go programs exhibit strongly generational behaviour, and the Go team are exploring potentially exploiting that in future with something they call the “request oriented collector”. It has been observed that this is essentially a renamed generational GC with a tweaked tenuring policy. Such a GC can be simulated in other runtimes for request/response processors by ensuring the young generation is large enough that all garbage generated by handling a request fits within it.

Despite that, Go’s current GC is not generational. It just runs a plain old mark/sweep in the background. Doing it this way has one advantage — you can get very very low pause times — but makes almost everything else worse.
..
But if you take one thing away, let it be this: garbage collection is a hard problem, really hard, one that has been studied by an army of computer scientists for decades. So be very suspicious of supposed breakthroughs that everyone else missed. They are more likely to just be strange or unusual tradeoffs in disguise, avoided by others for reasons that may only become apparent later.

Full article: https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.8eholkma7