<p>Someone I know and respect claimed the following: that for 30 years, people have <em>incorrectly</em> claimed to be able to create new GCs that allow for apps with much, much larger memory footprints. I can sort of see the reason why this would be difficult even today -- memory is far away from the CPU, so we need look-ahead caches and try to take advantage of locality and serial scanning. But even if we can scan pages serially, the pointers in these pages probably point to random virtual memory addresses...</p>
<p>So, if multiple cores are generating complex garbage very quickly, and the application has a large memory footprint with many pointers, how can Golang's GC handle the load? Will Golang's GC be a parallel GC?</p>
<p>Mostly, I want to know if Golang might be able to handle a long-lived application with multiple TB's of memory many pointers, with fast concurrent garbage generation. Or maybe such an app is not within Golang's design scope.</p>
<hr/>**评论：**<br/><br/>f2f: <pre><p>i could just tell you to search through the group, but instead i'll try to be more helpful. check this: </p>
<p><a href="http://www.infoq.com/presentations/go-gc-performance" rel="nofollow">http://www.infoq.com/presentations/go-gc-performance</a></p>
<p>see the slide around the 27 minute mark. that leaves a lot. and i mean <em>a</em> <em>lot</em> of room for applications. notice that we're talking 200, 250 gigabytes of heap sizes now! </p></pre>tendermint: <pre><p>Thanks. The slide shows GC pause time at around the 200, 250 GB range. I'm sure that pause time can be mitigated, but bounded pause time != effective GC, if the GC can't collect enough at the rate of generation. And the bigger the heap size, the more slower it will be to collect objects, right?</p></pre>SportingSnow21: <pre><p>The pause time is when all free memory is released to the stack/os. The entire stack and heap are scanned between STW pauses, so stale objects aren't ageing through multiple cycles.</p></pre>tendermint: <pre><p>Yes, but if the heap is huge, the scan time between STW pauses must get very long. For a fixed rate of garbage generation, if the heap is large enough, a single threaded GC routine won't be able to keep up.</p>
<p>I guess my question boils down to, is/will the Golang GC (become) parallel? This thread suggests that it is. <a href="https://groups.google.com/forum/#!searchin/golang-nuts/golang$20garbage$20collector$20parallel/golang-nuts/YaRDry8ZCYk/F5T1w5D-AwAJ" rel="nofollow">https://groups.google.com/forum/#!searchin/golang-nuts/golang$20garbage$20collector$20parallel/golang-nuts/YaRDry8ZCYk/F5T1w5D-AwAJ</a></p></pre>nussjustin: <pre><p>Go has a concurrent GC that normally uses 25% of your GOMAXPROCS threads for concurrent operations and only pauses for some cleanup work (which gets less with each release). If the GC can't keep up with your allocations it will force your goroutines to assist, thus slowing down allocations and shortening GCs. Also with Go 1.7 (coming out I think fall) the sweeper will be mostly "removed" (see <a href="https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md" rel="nofollow">https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md</a>)</p></pre>iends: <pre><p>The go team has made no promises yet, but it seems like it's been hinted at. It's certainly something they've seemed to consider.</p></pre>kjk: <pre><p>GC load is not about the size of memory but about the number of pointers that need to be scanned. 1TB []byte slice takes no time to GC. Create 1 GB of small structures that all reference each other via pointers and GC will spend a lot of time chasing those pointers.</p>
<p>That being said, no GC will keep up with terabytes of heavy allocations. Neither will straightforward manual management with malloc/free.</p>
<p>There is no magic technology that absolves you from perf tuning your program, especially if you're planning to do something that requires touching terabytes of memory. </p>
<p>If your program dos lots of randomly-sized, randomly ordered, small allocations with malloc()/free() (i.e. the "efficient" manual memory management) then even with the best memory allocator you'll spend majority of your CPU time in malloc()/free() calls and you'll fragment your memory and you'll find yourself having gigabytes of total free memory but unable to allocate a contiguous 1 MB chunk.</p>
<p>Go's GC used to be relatively simple but with 1.5 it's very good, will be even better in 1.6 and probably will continue to improve for Go's lifetime because, reading between the lines from Go commits, the improvements are driven by internal Google needs and if there's a company that exercises Go code with 1 TB of memory, that's Google.</p>
<p>Go's GC is probably in the top 5 implementation out there. Maybe Oracle's Java's GC is better and if you really need absolutely the best, you can give your money to Azule for their Java implementation.</p>
<p>If Go's GC is not good enough to keep up with your software, then you're unlikely to find a better implementation that will and it's time to start writing your code in a way that optimizes the thing that is slow. Generating lots of garbage is slow.</p>
<p>I once significantly sped up poppler by adding a simple custom memory allocator because the way the program was written, it was allocating a lot of (small) strings all over the place.</p>
<p>GC'ed code can also be optimized: use less pointers (you can e.g. replace pointers to objects with an index into an array of objects, the array serving as a custom pool allocator).</p>
<p>The good thing about Go is that it makes those kinds of memory optimizations much easier because, unlike Java where everything is a reference (i.e. a pointer), Go allows embedding structs by value.</p>
<p>For example, I've sped up a binary-trees benchmarks by 4x by implementing node references with integers, not pointers, and allocating nodes in bulk. See <a href="http://blog.kowalczyk.info/article/u5o7/Speeding-up-Go-and-C-with-custom-allocators.html" rel="nofollow">http://blog.kowalczyk.info/article/u5o7/Speeding-up-Go-and-C-with-custom-allocators.html</a></p></pre>
