5 ms·
What I especially like about this is getting the infrastructure needed to implement copying GC in early. This is really important to add at the beginning. It's
by pcwalton 8y ago
What I especially like about this is getting the infrastructure needed to implement copying GC in early. This is really important to add at the beginning. It's very costly to add it later once you have an entire production-quality engine built on top of non-moving or conservative GC.
(In fact I only know of one project that successfully made the transition from conservative to precise moving GC after many years of deployment: SpiderMonkey.)
- munificent 8y agoI believe Go initially had a conservative collector for the stack and switched to precise: https://github.com/golang/go/issues/5134 https://github.com/golang/go/issues/5134
- pcwalton 8y agoGo doesn't use moving GC. (Though the work needed to implement precise GC gets you a lot of the way to moving GC.)
- the_mitsuhiko 8y agoAnd given how much bad cgo code is out there i doubt they can ever change this.
- pcwalton 8y agoI wasn't aware of that. This is why you do moving GC early! Do you have more information on this? That sounds like very bad news for Go...
- repsilat 8y agoAside from the difficulty of changing, can you give a couple of sentences on the pros/cons? Are "moving GCs" mostly good for reducing fragmentation? I guess you'd get fewer annoying "holes" if you can compact memory, and better cache behaviour if live objects tend to be nearer to each other.
- foldr 8y agopcwalton has been outlining the cons of Go's GC on HN for quite some time :) https://duckduckgo.com/?q=pcwalton+go+gc+site%3Aycombinator.com&t=he&ia=web https://duckduckgo.com/?q=pcwalton+go+gc+site%3Aycombinator....
- jashmatthews 8y agoWhat do you think of the newer WebKit GC scheme where they removed compaction?