Is the GC still "stop the world"?

<p>It&#39;s been about a year or more since I was toying with go. I like to make games, and I like Go&#39;s syntax so it went well mostly. Lack of cross compiling and personal reasons led me to leave it but I&#39;m interested if the GC is still a problem? Especially for a game dev. Is cross compiling working too?</p> <hr/>**评论：**<br/><br/>DeedleFake: <pre><p>I&#39;m not exactly sure what you&#39;re talking about in terms of &#39;lack of cross compiling&#39;. Go&#39;s been very good at cross compiling for quite a while. All that&#39;s really required most of the time is</p> <pre><code>GOOS=target GOARCH=target go build </code></pre> <p>It can be complicated by cgo, but there are usually ways to get that to work, too.</p></pre>zxy_xyz: <pre><p>Awesome! I was probably going about it wrong before</p></pre>cjbprime: <pre><p><a href="https://groups.google.com/forum/m/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8" rel="nofollow">https://groups.google.com/forum/m/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8</a></p></pre>thesnowmancometh: <pre><p>This was a recent top post on the subreddit, but it&#39;s worth stating for OP that the link is worth your time. </p> <p>There are is still a Stop The World marking phase, but as far as I know all garbage collection requires a STW marking phase, as Real Time GC is a current, potentially unsolvable problem. </p></pre>throwdemawaaay: <pre><blockquote> <p>as Real Time GC is a current, potentially unsolvable problem.</p> </blockquote> <p>Azul shipped a <a href="http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf" rel="nofollow">pause free concurrent collector for the JVM</a>.</p> <p>It&#39;s really difficult and complex to build such a thing, but it&#39;s not an unsolved or unsolvable research problem.</p></pre>kjk: <pre><p>If you read the paper, they had to modify Linux kernel to support their collector and it only works on x86.</p> <p>So for the purpose of a language like Go, that has to work on unmodified Linux/Mac/Windows kernel and on variety of processors (x86, arm, mips, sparc), this is unsolved problem.</p></pre>mallocc: <pre><p>You refer to &#34;a language like Go&#34;. The Java language (among others) runs on the JVM across all those kernels and architectures among others. Not sure how the language is relevant, it&#39;s the runtime that matters. </p> <p>Yes, Azul is unique in that it messes with the kernel, it could do the same for a Go runtime too. It&#39;s a solved problem on a single architecture and OS for one particular runtime. Nothing language specific about it. </p></pre>throwdemawaaay: <pre><p>Yup, I have read the paper and I&#39;m familiar with the limitations of how their barrier works both on their cpus as well as on vms.</p> <p>The choice they made does not make the statement &#34;Real Time GC current, potentially unsolvable problem&#34; true. It also doesn&#39;t exclude the possibility of a similar design using a different barrier mechanism. In particular golang has the advantage of control of the compiler, so they could use a barrier technique that requires changing the output code at every memory access if they needed/wanted.</p> <p>Note also that there are other gc&#39;s considered real time, such as IBM&#39;s Metronome. With the latest changes golang&#39;s gc is in the same rough ballpark. It would not surprise me in the slightest if given a year or two more contributions as smart as we&#39;ve seen the last year, go gets to a real time gc.</p> <p>I&#39;m unaware of anything that excludes the possibility of go getting a fully pauseless gc as well, though I think that&#39;s going to be more difficult to make efficient enough vs a very short duration and frequency hard bounded pause.</p></pre>Mythiix: <pre><p>Cross compilation has been super easy since Go 1.5, circa March 2015</p> <p>Garbage collection is recently much improved. Go is certainly well suited to be a game server IMO. With the new improvements in GC it may be suitable for client. Challenge is a good graphics library or rolling your own</p></pre>the_birds_and_bees: <pre><p>Since go1.5 the GC has been largely concurrent but with short stw pauses at certain points in the algorithm. in 1.6,1.7 and coming up in 1.8 there have been successive improvements to improve the worst case stw times. Upper bound in 1.8 is ~100 microseconds.</p> <p>Whether that&#39;s good enough for your application will depends a lot on the details of what you&#39;re trying to do.</p></pre>