runtime: fix build

'range hash' makes a copy of the hash array in the stack, creating
a very large stack frame. It's just the right amount that it
uses most but not all of the total stack size. If you have a lot
of environment variables, like the builders, then this is too
much and the g0 stack runs out of space.

TBR=bradfitz
CC=golang-codereviews
https://codereview.appspot.com/132350043
runtime: fix arm build

LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/134030043

Committer: Russ Cox <rsc@golang.org>
database/sql: use slices rather than container/list

Significantly reduces the number of allocations, while also
simplifying the code and increasing performance by a 1-2%.

benchmark                          old ns/op     new ns/op     delta
BenchmarkConcurrentDBExec          13290567      13026236      -1.99%
BenchmarkConcurrentStmtQuery       13249399      13008879      -1.82%
BenchmarkConcurrentStmtExec        8806237       8680182       -1.43%
BenchmarkConcurrentTxQuery         13628379      12756293      -6.40%
BenchmarkConcurrentTxExec          4794800       4722440       -1.51%
BenchmarkConcurrentTxStmtQuery     5040804       5200721       +3.17%
BenchmarkConcurrentTxStmtExec      1366574       1336626       -2.19%
BenchmarkConcurrentRandom          11119120      10926113      -1.74%

benchmark                          old allocs     new allocs     delta
BenchmarkConcurrentDBExec          14191          13684          -3.57%
BenchmarkConcurrentStmtQuery       16020          15514          -3.16%
BenchmarkConcurrentStmtExec        4179           3672           -12.13%
BenchmarkConcurrentTxQuery         16025          15518          -3.16%
BenchmarkConcurrentTxExec          12717          12709          -0.06%
BenchmarkConcurrentTxStmtQuery     15532          15525          -0.05%
BenchmarkConcurrentTxStmtExec      2175           2168           -0.32%
BenchmarkConcurrentRandom          12320          11997          -2.62%

benchmark                          old bytes     new bytes     delta
BenchmarkConcurrentDBExec          2164827       2139760       -1.16%
BenchmarkConcurrentStmtQuery       2418070       2394030       -0.99%
BenchmarkConcurrentStmtExec        1728782       1704371       -1.41%
BenchmarkConcurrentTxQuery         2477144       2452620       -0.99%
BenchmarkConcurrentTxExec          588920        588343        -0.10%
BenchmarkConcurrentTxStmtQuery     790866        796578        +0.72%
BenchmarkConcurrentTxStmtExec      98502         98143         -0.36%
BenchmarkConcurrentRandom          1725906       1710220       -0.91%

LGTM=ruiu, dave, bradfitz
R=golang-codereviews, ruiu, gobot, bradfitz, dave, minux
CC=bradfitz, golang-codereviews
https://codereview.appspot.com/107020044

Committer: Brad Fitzpatrick <bradfitz@golang.org>
cmd/api: more runtime fixes

This is getting a little annoying, but once the runtime structs are
being defined in Go, these will go away. So it's only a temporary cost.

TBR=bradfitz
CC=golang-codereviews
https://codereview.appspot.com/135940043
spec: move Method expr/value section near selectors

Preparation for fixing issue 5769 (method selectors
do not auto-dereference): The actual fix may require
some cleanups in all these sections, and syntactically,
method expressions and method values are selector
expressions. Moving them next to each other so that
it's easy to see the actual changes (next CL).

No content changes besides the section moves.

LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://codereview.appspot.com/132300043