Hacker News Reader

Comment by nulltype | Hacker News Reader

Here's the paper on the Zing JVM's C4 GC: http://www.azulsystems.com/sites/default/files/images/c4_pap...

I'm not sure how much of it applies to Go, but I'm guessing it's quite a bit more complicated than the current collector. It also may only work on 64 bit X86 hardware (which is fine by me, but looks like a subset of what go currently supports).

There's a simpler overview in http://www.azulsystems.com/sites/default/files//images/wp_pg...

View on HN

One of the C4 authors posted some advice on golang-dev a while back:

https://groups.google.com/d/msg/golang-dev/GvA0DaCI2BU/1EpYa...

The good news is Go has been chipping away at that stuff.

That was a great thread thanks for linking it! If Go wants to be a serious solution in many applications pauseless GC needs to happen and until it does it will be just like all the other solutions that can't play at scale and low latency. If it stays in that zone it'll have to compete with a very large set of perfectly fine solutions with massive libraries and lots of people who know how to code in those languages.

The problem with C4 is that it requires a kernel module, so it's obviously not suitable as the primary GC.

That's a good point and often passed over when talking about C4. It's a real shame, because that is a fairly large sticking point. There was an attempt to get the kernel changes needed by C4 pushed into the standard kernel, but I remember it got a lot of push-back by the kernel devs.

Reply on news.ycombinator.com