CL 56120043 fixed and cleaned up TLS on ARM after introducing liblink, but
left flag_shared broken. This CL restores the (unsupported) flag_shared
behaviour by simply rewriting access to $runtime.tlsgm(SB) with
runtime.tlsgm(SB), to compensate for the extra indirection when going from
the R_ARM_TLS_LE32 relocation to the R_ARM_TLS_IE32 relocation.

Also, remove unnecessary symbol lookup left after 56120043.

LGTM=iant
R=iant, rsc
CC=golang-codereviews
https://golang.org/cl/57000043

CL 56120043 fixed TLS handling on ARM after the introduction of
liblink but left older ARM processors broken.

Before liblink, the MRC instruction was replaced with a fallback
on older ARMs. CL 56120043 removed that, because the rewrite matched
bit patterns on the AWORD pseudo-instruction and could therefore change
unrelated AWORDs that happened to match.

This CL adds an AMRC instruction to encode both MRC and MCR previously
encoded as AWORDs. Then, in liblink, the AMRC instructions are either
rewritten to AWORD, or, on goarm < 7, replaced with a branch to the
fallback.

./all.bash completes successfully on an ARMv7 with either GOARM=7 or
GOARM=5. I have verified that the fallback is indeed present in both
runtime.save_gm and runtime.load_gm when GOARM=5 but not when GOARM=7.

If all goes well, this should fix the armv5 builders.

LGTM=iant
R=iant, rsc
CC=golang-codereviews
https://golang.org/cl/55540044

Command was (and is) documented like:
"If name contains no path separators, Command uses LookPath to
resolve the path to a complete name if possible. Otherwise it
uses name directly."

But that wasn't true. It always did LookPath, and then
set a sticky error that the user couldn't unset.
And then if cmd.Dir was changed, Start would still fail
due to the earlier sticky error being set.

This keeps LookPath in the same place as before (so no user
visible changes in cmd.Path after Command), but only does
it when the documentation says it will happen.

Also, clarify the docs about a relative Dir path.

No change in any existing behavior, except using Command
is now possible with relative paths. Previously it only
worked if you built the *Cmd by hand.

Fixes #7228

LGTM=iant
R=iant
CC=adg, golang-codereviews
https://golang.org/cl/59580044

LGTM=dave
R==r, r, dave
CC=golang-codereviews
https://golang.org/cl/59810043

Generated by addca.

LGTM=iant
R=gobot, iant
CC=golang-codereviews
https://golang.org/cl/59770043

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59550044

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/51430044

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59410044

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59450044

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59460043

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/54800045

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59450043

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59440043

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/56730044

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59430043

Generated by addca.

TBR=iant
R=gobot
CC=golang-codereviews
https://golang.org/cl/59420043

Fixes #6874.

Use runtime.GC() as a stronger version of runtime.Gosched() which tends to bias the running goroutine in an otherwise idle system. This appears to reduce the worst case number of spins from 600 down to 30 on my 2 core system under high load.

LGTM=iant
R=golang-codereviews, lucio.dere, iant, dvyukov
CC=golang-codereviews
https://golang.org/cl/56540046

No functional changes, just more readable code.

LGTM=r
R=golang-codereviews, gobot, r
CC=golang-codereviews
https://golang.org/cl/59240043

If a LowerUpper ever happens, maketables will complain.

Fixes #7002.

LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/59210044

LGTM=r
R=golang-codereviews, r, arnehormann, bradfitz
CC=golang-codereviews
https://golang.org/cl/58450043

I don't know what is n, but it exists somewhere there.

LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/58710043

LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=dave, golang-codereviews
https://golang.org/cl/58900044

LGTM=rsc, dave
R=golang-codereviews, dave, josharian, rsc
CC=golang-codereviews
https://golang.org/cl/46490043

Array values are comparable if values of the array element type
are comparable.

Fixes #6526.

LGTM=khr
R=rsc, bradfitz, khr
CC=golang-codereviews
https://golang.org/cl/58580043

In external link mode the linker explicitly adds the string
constant "runtime/cgo".  It adds the string constant using the
same symbol name as the compiler, but a different format.  The
compiler assumes that the string data immediately follows the
string header, but the linker puts the two in different
sections.  The result is bad string data when the compiler
sees "runtime/cgo" used as a string constant.

The compiler assumption is in datastring in [568]g/gobj.c.
The linker layout is in addstrdata in ld/data.c.  The compiler
assumption is valid for string literals.  The linker is not
creating a string literal, so its assumption is also valid.

There are a few ways to avoid this problem.  This patch fixes
it by only doing the fake import of runtime/cgo if necessary,
and by only creating the string symbol if necessary.

Fixes #7234.

LGTM=dvyukov
R=golang-codereviews, dvyukov, bradfitz
CC=golang-codereviews
https://golang.org/cl/58410043

Update #7237

LGTM=bradfitz
R=jas, bradfitz
CC=golang-codereviews
https://golang.org/cl/57190045

Tcmalloc uses 8K, 32K and 64K pages, and in custom setups 256K pages.
Only Chromium uses 4K pages today (in "slow but small" configuration).
The general tendency is to increase page size, because it reduces
metadata size and DTLB pressure.
This change reduces GC pause by ~10% and slightly improves other metrics.

json-1
allocated                 8037492      8038689      +0.01%
allocs                     105762       105573      -0.18%
cputime                 158400000    155800000      -1.64%
gc-pause-one              4412234      4135702      -6.27%
gc-pause-total            2647340      2398707      -9.39%
rss                      54923264     54525952      -0.72%
sys-gc                    3952624      3928048      -0.62%
sys-heap                 46399488     46006272      -0.85%
sys-other                 5597504      5290304      -5.49%
sys-stack                  393216       393216      +0.00%
sys-total                56342832     55617840      -1.29%
time                    158478890    156046916      -1.53%
virtual-mem             256548864    256593920      +0.02%

garbage-1
allocated                 2991113      2986259      -0.16%
allocs                      62844        62652      -0.31%
cputime                  16330000     15860000      -2.88%
gc-pause-one            789108229    725555211      -8.05%
gc-pause-total            3945541      3627776      -8.05%
rss                    1143660544   1132253184      -1.00%
sys-gc                   65609600     65806208      +0.30%
sys-heap               1032388608   1035599872      +0.31%
sys-other                37501632     22777664     -39.26%
sys-stack                 8650752      8781824      +1.52%
sys-total              1144150592   1132965568      -0.98%
time                     16364602     15891994      -2.89%
virtual-mem            1327296512   1313746944      -1.02%

This is the exact reincarnation of already LGTMed:
https://golang.org/cl/45770044
which must not break darwin/freebsd after:
https://golang.org/cl/56630043
TBR=iant

LGTM=khr, iant
R=iant, khr
CC=golang-codereviews
https://golang.org/cl/58230043

The Transport's idle connection cache is keyed by a string,
for pre-Go 1.0 reasons.  Ever since Go has been able to use
structs as map keys, there's been a TODO in the code to use
structs instead of allocating strings. This change does that.

Saves 3 allocatins and ~100 bytes of garbage per client
request. But because string hashing is so fast these days
(thanks, Keith), the performance is a wash: what we gain
on GC and not allocating, we lose in slower hashing. (hashing
structs of strings is slower than 1 string)

This seems a bit faster usually, but I've also seen it be a
bit slower. But at least it's how I've wanted it now, and it
the allocation improvements are consistent.

LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/58260043

Fixes #6323.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/56870043

LGTM=mischief, mikioh.mikioh
R=golang-codereviews, 0intro, mischief, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/53960044

The code is copied from cmd/6g.
Empirically, all branch targets are nil in this code so
something is still wrong, but at least this stops 8g -S
from crashing.

Update #7178

LGTM=dave, iant
R=iant, dave
CC=golang-codereviews
https://golang.org/cl/58400043

Ensure than heap is PageSize aligned.

LGTM=iant
R=iant, dave, gobot
CC=golang-codereviews
https://golang.org/cl/56630043

This is the chunked half of https://golang.org/cl/49570044 .

We want full reads to return EOF as early as possible, when we
know we're at the end, so http.Transport client connections are eagerly
re-used in the common case, even if no Read or Close follows.

To do this, make the chunkedReader.Read fill up its argument p []byte
buffer as much as possible, as long as that doesn't involve doing
any more blocking reads to read chunk headers. That means if we
have a chunk EOF ("0\r\n") sitting in the incoming bufio.Reader,
we see it and set EOF on our final Read.

LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/58240043

Set EOF on the final Read of a body with a Content-Length, which
will cause clients to recycle their connection immediately upon
the final Read, rather than waiting for another Read or Close
(neither of which might come).  This happens often when client
code is simply something like:

  err := json.NewDecoder(resp.Body).Decode(&dest)
  ...

Then there's usually no subsequent Read. Even if the client
calls Close (which they should): in Go 1.1, the body was
slurped to EOF, but in Go 1.2, that was then treated as a
Close-before-EOF and the underlying connection was closed.
But that's assuming the user even calls Close. Many don't.
Reading to EOF also causes a connection be reused. Now the EOF
arrives earlier.

This CL only addresses the Content-Length case. A future CL
will address the chunked case.

LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/49570044

LGTM=bradfitz
R=jas, mikioh.mikioh, bradfitz
CC=golang-codereviews
https://golang.org/cl/51200045

Fixes #7183.

LGTM=iant
R=golang-codereviews, gobot, iant
CC=golang-codereviews
https://golang.org/cl/57520043

This change also addresses some places where the comments were lacking.

Fixes #7087.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/56700043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/57390043

json-1
cputime                  99600000     98600000      -1.00%
time                    100005493     98859693      -1.15%

garbage-1
cputime                  15760000     15440000      -2.03%
time                     15791759     15471701      -2.03%

LGTM=khr
R=golang-codereviews, gobot, khr, dave
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/57310043

On 32-bits one can arrange make(chan) params so that
the chan buffer gives you access to whole memory.

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant, khr
https://golang.org/cl/50250045