

Go 1.6 GC improvements - artursapek
https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo

======
twotwotwo
It looks like a few things in there could further reduce typical and peak
pause times, by backgrounding more phases of the work and rescanning stacks
late so it's less likely much marking has to happen in the pause. I'm less
clear on this, but "embrace write barrier during scan" and the other pacing
changes might also better spread out work during the concurrent phases.

The pause improvements in 1.5 are no joke -- here's a benchmark from the
GopherCon talk on it:
[http://i.stack.imgur.com/4TOux.png](http://i.stack.imgur.com/4TOux.png) (1.5
is the yellow dots along the bottom)

(That talk is
[https://www.youtube.com/watch?v=aiv1JOfMjm0](https://www.youtube.com/watch?v=aiv1JOfMjm0)
and the slides are [https://talks.golang.org/2015/go-
gc.pdf](https://talks.golang.org/2015/go-gc.pdf) )

And here's a graph from a real-world memory hungry app on a beta--300ms pause
down to 4ms:
[https://twitter.com/mkevac/status/620872308446625792/photo/1](https://twitter.com/mkevac/status/620872308446625792/photo/1)

(Presentation on that app here:
[http://www.slideshare.net/MarkoKevac/markogoinbadoo](http://www.slideshare.net/MarkoKevac/markogoinbadoo)
)

Another app's pauses went from ~12ms to ~2ms:
[https://twitter.com/inconshreveable/status/62065078666255564...](https://twitter.com/inconshreveable/status/620650786662555648/photo/1)

And this doc means Go _isn 't_ moving to a generational GC now, which the
pre-1.4 proposal speculated they might do in 1.6. That would mostly be a
throughput win (discard short-lived garbage cheaply and early, so full GCs can
be rarer), not a pause win (it could add _new_ short pauses for young-gen
GCs). Seems sane for now, since the polish they're talking about seems
difficult, directly useful, and important as a basis for future work, and the
pauses seem like the larger headache for the working Gopher anyway.

~~~
tedunangst
I've wondered for a while how much go could benefit from better escape
analysis. Especially if they don't do generational.

Intuitively, it seems quite some escapes are only returned to the caller, then
lost. If the compiler rewrote those functions as operating on references to
caller provided memory (on the stack), it could reduce transient garbage.

~~~
twotwotwo
So, watching [https://twitter.com/golang_cls](https://twitter.com/golang_cls),
some escape-analysis and general garbage-prevention stuff landed (much from,
or with the involvement of, the always-amazing Dmitry Vyukov).

Maps don't always escape now, for example: [https://go-
review.googlesource.com/#/c/3508/](https://go-
review.googlesource.com/#/c/3508/)

Code was added to recognize that some ops don't cause escaping: [https://go-
review.googlesource.com/#/c/3031/](https://go-
review.googlesource.com/#/c/3031/) [https://go-
review.googlesource.com/#/c/8201/](https://go-
review.googlesource.com/#/c/8201/) [https://go-
review.googlesource.com/#/c/3162/](https://go-
review.googlesource.com/#/c/3162/)

dvyukov wrote about some potential improvements and linked to issues in Feb:
[https://docs.google.com/document/d/1CxgUBPlx9iJzkz9JWkb6tIpT...](https://docs.google.com/document/d/1CxgUBPlx9iJzkz9JWkb6tIpTe5q32QDmz8l0BouG0Cw/edit#)

I think I saw even string bytes can be stack-allocated sometimes now, but
couldn't immediately find the CL.

It looks like this is one of those things where one just has to chip away at
cases. Movement happening; just a ton of round tuits required.

------
TheMagicHorsey
I have a question that maybe doesn't belong here. I know people have asked a
lot of questions about Go in a skeptical way, and I promise I'm not coming at
it from that angle. I actually use Go quite a bit (mostly on App Engine) so I
do like it.

My question is, given all the things being built around Go, like Kubernetes
and various other job and cluster management tools, why weren't those things
absorbed into the language or standard library. The way, say it is with
Erlang?

In Erlang a lot of the multi-machine coordination work seems to be really well
thought out, and its part of their standard OTP library ... which seems pretty
mature (at least to someone who is a novice like me).

Why doesn't Google use Erlang? And if they don't use Erlang, why isn't there
some sort of cluster management stuff built into Go?

I mean things like cross machine channels, automatic go-routine (or process)
restart on failure, process monitoring, etc.

~~~
jerf
"Why doesn't Google use Erlang? And if they don't use Erlang, why isn't there
some sort of cluster management stuff built into Go?"

Cluster management is a hard problem. Erlang's cluster support really only
hits one use case, which is that you've got a relatively small cluster... at
least, by Google standards!... of several machines physically co-located, or
at least, _very_ close on the network together. That's a great use case to
cover, but it is important to understand that's "all" it is. You can't build a
1000-machine, multiple-data center located around the world deployment on the
default Erlang stack as if all those machines are on one cluster. What Erlang
gives you is still a step up from the normal default; you can build that as a
cluster in each DC and it's not that hard to start up "proxy processes" that
allow you to talk to other machines in the data cluster via Erlang messages
sent to processes... but now you're talking about doing work, not just using
built-in support.

"cross-machine channels" are, in my considered opinion, impossible. The
channel semantics include a synchronous rendevous that is impossible to
guarantee over the network. (That is, when you advance past a channels send
statement to a non-buffered channel, you are _guaranteed_ that some other
goroutine has received the value.) You can set up other objects that let you
communicate remotely, but they can't be "channels"... they can only be other
things.

(Note that you have to understand "Go channel" not as a vague "something that
lets you send messages", but the specific and _exact_ semantics it implements,
which is _important_ because without those very specific semantics, "select"
doesn't work! And if you can't put it in a "select", it isn't a Go channel. Go
channels have a very, _very_ rich semantics full of strong guarantees, which
can't be relayed across a network.)

Some of the rest of your last paragraph is fairly deeply addressed in this
post of mine:
[http://www.jerf.org/iri/post/2930](http://www.jerf.org/iri/post/2930)

~~~
azth
> Go channels have a very, very rich semantics full of strong guarantees,
> which can't be relayed across a network.)

Any place to read up on those guarantees?

~~~
jerf
The Go specification has them all, though perhaps not in the tabular format
you might have liked:
[http://golang.org/ref/spec#Channel_types](http://golang.org/ref/spec#Channel_types)
Be sure to follow the links through to the "select" statement and the other
operations.

Some of what I was discussing is merely implied, rather than spelled out. A
spec does not discuss the consequences of failing to implement it. However, if
you could imagine a "network channel" somehow making its way into a "select"
statement that the programmer expects to, you know, actually work the way the
specification says it should, it could be a huge error to discover that your
"network channel" actually triple-sent some message before the ACK finally
came back or something.

------
sitharus
I feel like sharing google docs links is the new emailing a Word document. I'm
sure loading a static HTML page faster for the features needed.

~~~
tedunangst
The best part is that if you read it on iPhone, every two minutes it switches
tasks to the App Store trying to get you to download the app. Not once, not
twice, repeatedly.

~~~
rattray
Stuff like that is why I switched to Android. Had to go back to iPhone for a
couple weeks recently and couldn't stand the poor inter-app coordination.

------
ascii_lover
Is there a way to have docs.google.com serve up plain text?

~~~
NightMKoder
Looks like there is. Given

[https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6of...](https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/preview)

change "preview" to "export?format=txt":

[https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6of...](https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/export?format=txt)

~~~
tedunangst
A+++ for the second link. Would read again.

------
enahs-sf
I feel guilty as I haven't even upgraded to go 1.5 yet.

~~~
zac1944
i will wait 1.6 too.

~~~
nindalf
You're missing out, to be honest. Moving to Go 1.5 is painless and the latency
wins are huge.

~~~
pkroll
Well, like landr0id says it's not "stable" yet... although it's on release
candidate 1, so it's pretty close. Once 1.5 stable comes out it'd be silly to
wait for 1.6, 'cause that's 6 months away.

------
namelezz
Anyone knows when Go is going to have generics.

~~~
recentdarkness
This SO question covers this question quite well:
[http://stackoverflow.com/questions/3912089/why-no-
generics-i...](http://stackoverflow.com/questions/3912089/why-no-generics-in-
go/3912095#3912095)

Beside the accepted answer, there are also some other useful answers included.

