
Go’s march to low-latency GC - etrevino
https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.9lsrreb5u
======
_ph_
Another very nice feature of Go is, that since 1.5, the whole runtime,
including the GC is written in Go itself. So every Go developer can look at
the implementation. The GC itself is surprisingly small amount of code.

~~~
colordrops
Excuse my obvious ignorance, but how is the GC written in Go? The GC in Go is
not optional, right? Does the GC use GC? Turtles all the way down?

~~~
uluyol
How does one implement malloc in C? (Edit: ignore this. As pointed out in the
responses, this actually different since GC calls are inserted by the
compiler)

Unsafe code, direct syscalls, using only a subset of language features, and
coupling to the compiler (both for generating data used by the GC as well as
inserting calls into the runtime in appropriate places).

None of this would really be any different if implemented in C. C is clearly
an unsafe language, the syscalls would still be there, as would the coupling
to the compiler. The difference is that you have to have a fast way to call
from Go into C. With Go this is unnecessary.

Of course if you're really curious, you can always check out the source :)

~~~
haberman
There is a pretty big difference between these two cases.

In C, calls to malloc() are explicit. You implement malloc() in C by not
calling malloc().

In GC'd languages, the language runtime calls the garbage collector
implicitly. So you need some more clever way of ensuring that these implicit
calls do not occur. You also need to ensure that no garbage is created that
will leak without a GC.

------
r1ch
I have to wonder - when you're digging down into this level of complexity in
order to discover issues with the language you're using, wouldn't something
like C be better? IRC isn't a very hard protocol and you know the language
won't be getting in your way if you're using C.

~~~
topspin
Reading this causes me to experience déjà vu; years and years of reading
stories and watching presentations about someone struggling with GC in the
JVM. It's happening all over again with Go. The same 'discoveries', the same
trade-offs, the same discussions about hardware resources, the same
'concurrent mark and sweep', the same 'more to do' conclusions. You could
replace every occurrence of 'Go' with 'Java' and it would probably go
undiscovered.

Maybe it's all worth it and this is how developers are supposed to spend their
time, but it's no longer interesting to me.

~~~
arcticbull
It's because GC is a bad idea that's had 30 years of good research thrown
after it. Advancing GC is building a faster horse instead of stepping back and
building a car. It's time to move on, and I'm thrilled to see modern languages
(Swift, Rust) abandoning it and focusing on building more intelligent
compilers.

The goal shouldn't ever be to make the world's best GC, it should be to create
the world's best way to elide lifetimes so that developers don't have to think
about memory management. GC shouldn't be a goal, it's a technique for solving
a problem, one of many that we should explore.

~~~
aserafini
Seems like the opposite surely? We should be developing languages that more
succinctly address the problems we humans are trying to solve not book keeping
for the computer's hardware (that should be the computers job!).

~~~
weberc2
I think you missed the bit where he said "more intelligent compiler". The
compiler is the bit that does the bookkeeping, only in Rust (and evidently
Swift--I haven't played with it much) it's done statically, ahead of time
rather than at runtime.

That said, I think Go is a much more practical language than Rust for most
problems. __That said __, I 'm still very excited about Rust.

~~~
arcticbull
Yeah, that's exactly what I was trying to say. Rust does all the bookkeeping
at compile time, Swift keeps a lot of it at run-time although the compiler can
easily optimize away a lot of lifecycle stuff too when it's in scope, so I
assume it either does or will.

I agree that Rust likely does not have the be-all answer to automatic memory
management, though what I love about it is that they're pushing the boundaries
and getting people thinking differently about memory management.

~~~
weberc2
> I agree that Rust likely does not have the be-all answer to automatic memory
> management, though what I love about it is that they're pushing the
> boundaries and getting people thinking differently about memory management.

Me too. I intend to use it for more of my hobby things, but Go is currently
the best fit. Eventually I imagine Rust will pick up some decent GUI libraries
or at least get decent editor support (vim-go is lightyears ahead of
YCM+racer) and I'll be able to afford to justify using it more.

------
ben_jones
This may be anecdotal but Twitch is an example of a service that just bloody
works. I've been a user for awhile and I've yet to notice any noticeable
service disruptions or issues. They were also one of the largest early
adopters of EmberJS, pretty sure it was well before the 1.0 release when many
bugs were still being worked out and the API suffered frequent changes, so
hats off to the engineering team for continued awesome work.

~~~
hdra
Maybe if you have fast internet connection. I'm on a HSDPA+ connection and
Twitch is unusable, not even the VODs. Then again, Youtube and Vimeo is pretty
much the only sites from which I can watch video streams smoothly.

~~~
predakanga
I'm curious, have you tried viewing the streams or VODs through an alternate
player?

I've found that I can almost always improve the smoothness of their content by
using Livestreamer[0] to play it in VLC (or Kodi, more often)

[0]: [http://docs.livestreamer.io](http://docs.livestreamer.io)

~~~
83457
I use this on my netbook. Pretty much unwatchable otherwise

------
anonymousDan
So how does the GC performance of Go compare to something like Java/the
Hotspot JVM?

~~~
_ph_
The approaches to GC are difficult to compare, and Java offers a selection of
garbage collectors. Overall, the Java collectors are very sophisticated and
tuned over years, so in principle are excellent. The downside is, that the
Java language itself puts a lot of stress on the GC. The biggest problem is,
that Java offers no "value" types beyond the builtin int, double,... So
everything else has to be allocated as a separate object and pointed to via
references. The GC then has to trace all these references, which takes time.
While a collection of the youngest generation in Java is extremely fast, a
global GC can take quite some time.

Go on the other side has structs as values, so the memory layout is much
easier for the GC. Go always performs full GCs, but mostly running in parallel
with the application, a GC cycle only requires a stop-the-world phase of a few
milliseconds (for multi gigabyte heaps).

All these numbers of course depend a lot on what your application is doing,
but overall Go seems to be doing very well with its newest iterations of the
GC.

~~~
Cyph0n
Another strong point for the JVM is the availability of alternate
implementations from several vendors. Is this possible for Go say in the
future?

~~~
_ph_
It is certainly possible. There are already two Go implementations, the
official one, and a gcc based one. And due to the fact that the whole Go
implementation is available under BSD license, allows anyone without any
license worries to fork a custom Go implementation.

~~~
lloeki
You forgot GopherJS.

------
thegeekpirate
Posted earlier without the random hash in the URL
[https://news.ycombinator.com/item?id=12040349](https://news.ycombinator.com/item?id=12040349)

------
fauigerzigerk
That's interesting, but it would be even more interesting if the article
contained some info about heap sizes, memory utilization and the number of CPU
cores.

------
pepesza
I think that not using Erlang in this particular case was a mistake. Erlang is
running some of the largest chats out there, including League of Legends and
WhatsApp. They would have avoided all the hassle of GC pauses, since Erlang
has per-process GC collection. And scaling single OS process to their number
of connections was done for Erlang machines years ago.

~~~
woodcut
Finding an erlang programmer available on site within 1-2 months is the
hardest part of deciding to go with erlang. With go you can take a C++/python
programmer and have them writing production code pretty soon, i think this is
what inhibits functional programming in general, the learning curve bundled
with the amount of work around prevents people jumping onboard also
willingness of some employers to hire someone without a ton of exp. with
erlang makes it difficult for a senior programmer to switch.

~~~
gtrubetskoy
>> With go you can take a C++/python programmer and have them writing
production code pretty soon

In my experience, learning Go (and by that I mean fully grasping the ways of
Go, goroutines, channels, selects, interfaces, type switches, etc) takes at
least a year for someone whose background is C/Python/Ruby. Then may be it's
just me.

~~~
spyspy
It took me a good 3 months of fighting with the language before it started to
click for me, and then another 3 months to really start using it properly. It
sucks to always read things like "I was able to write production code on the
first day!" around here.

~~~
koffiezet
I think that depends on the mindset of how you see computer languages. I like
learning new languages, every time I encounter some new language, I have to
try it out and get at least something basic working.

I'm pretty decent at C, C++, Python and Bash scripting, have participated in
larger projects in Java, Perl, Pascal/Delphi and Ruby, and have toyed around
with Rust, Haskell, Clojure, Angelscript, Crystal, Lua and probably a bunch
more that I forget.

Go for me was a breeze, everything just clicked. It helps that it got a lot of
it's inspiration from other languages I already knew pretty well. When started
toying around with Haskell for example, this wasn't the case, it took me quite
a while to get me up & running with the basics, and I still don't think I know
basic Haskell. Go on the other hand was easy, and within a week I was diving
into the stdlib sourcecode.

------
iamleppert
I'm curious why you didn't just use something like Redis for managing
concurrent state and pair that to any of the various web apps that are good at
concurrent connections? You could still use Go to serve the web
requests/sockets/etc.

~~~
smegel
> But this isn’t another article about how great Go is for us — it’s about how
> our use of Go pushes the limits of the current runtime implementation in
> some dimensions, and how we respond to reaching those limits.

------
lllorddino
Before Go I was web developing in Node.js but wanted to get "closer to the
metal." Thought about using C for the back end but then heard about Go and
have been in love ever since. My favorite programming language by far.

------
jeffdavis
There has been a ton of research for GC on the JVM. What are the differences
between Go's approach and Java's? Are those differences due to linguistic
differences or different goals?

~~~
cbsmith
There was a ton of research of LISP & Smalltalk GC's prior to the advent of
the JVM.

~~~
jeffdavis
So what are the trade-offs? Is each language re-inventing the wheel, or is it
just a matter of implementation effort?

~~~
cbsmith
I've found each language, out of expediency, often starts with a comparatively
crude implementation of GC, and then gradually improves upon their work,
leveraging knowledge from other platforms.

That said, gc is very subtle, and each runtime has unique characteristics that
mean that what works best for one might not be ideal for others.

------
amelius
How do they prove correctness of their GC?

~~~
coldtea
They run lots of programs and see if they crash/leak.

(Seriously, Go is not really an academic language caring for that kind of
stuff, unless it comes off easily to prove it).

------
mkevac
> Next up is runtime.scanobject. That function does several things, but the
> reason it’s running during the chat server’s mark termination phase in Go
> 1.5 is to implement finalizers.

How did you know that?

> We emailed back and forth and the Go team was very helpful with suggestions
> on how to diagnose the performance problems and how to distill them into
> minimal test cases.

Can you give us the link?

------
_pmf_
Purposefully strolling to where the puck was in 2001.

