3 ms·
Here's the paper on the Zing JVM's C4 GC: http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf http://www.azulsystems.com/sites/default/files/
by nulltype 12y ago
Here's the paper on the Zing JVM's C4 GC: http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf 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_pgc_zing_v5.pdf http://www.azulsystems.com/sites/default/files//images/wp_pg...
- hedgehog 12y agoOne of the C4 authors posted some advice on golang-dev a while back: https://groups.google.com/d/msg/golang-dev/GvA0DaCI2BU/1EpYa8HbxdIJ https://groups.google.com/d/msg/golang-dev/GvA0DaCI2BU/1EpYa... The good news is Go has been chipping away at that stuff.
- kator 12y agoThat 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.
- tomp 12y agoThe problem with C4 is that it requires a kernel module, so it's obviously not suitable as the primary GC.
- fmstephe 12y agoThat'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.