This cleans up the code significantly, and it avoids any
possible problems with madvise zeroing out some but
not all of the data.

Fixes #6400.

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

The issue was that one of the MSpan_Sweep callers
was doing sweep with preemption enabled.
Additional checks are added.

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

LGTM=rsc
R=rsc, jas, gobot
CC=ality, golang-codereviews
https://golang.org/cl/51650051

TestLookupHost expects that no duplicate addresses are returned. when cs is consulted for a name, e.g net!localhost!1, it will possibly return multiple available paths, e.g. via il and tcp. this confuses the tests.

LGTM=aram
R=jas, 0intro, aram
CC=golang-codereviews
https://golang.org/cl/58120045

This adds support for archives with the SCHILY.xattr field in the
pax header. This is what gnu tar and star generate.
Fixes #7154.

LGTM=dsymonds
R=golang-codereviews, gobot, dsymonds
CC=golang-codereviews
https://golang.org/cl/54570043

While we're at it, fix a wrong for statement in cmd/8g.

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

warning: src/cmd/gc/popt.c:700 format mismatch d VLONG, arg 4
warning: src/cmd/gc/popt.c:700 format mismatch d VLONG, arg 5

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/62910043

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/62960043

This seems to be what causes the 'chunk mismatch' errors.
I don't know why the server tells us there's nothing to upload,
but at the least we can warn that it did, so that the user
will try again.

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

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62890043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62880043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62870043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62860043

copyau1 was assuming that it could deduce the type of the
middle register p->reg from the type of the left or right
argument: in CMPF F1, F2, the p->reg==2 must be a D_FREG
because p->from is F1, and in CMP R1, R2, the p->reg==2 must
be a D_REG because p->from is R1.

This heuristic fails for CMP $0, R2, which was causing copyau1
not to recognize p->reg==2 as a reference to R2, which was
keeping it from properly renaming the register use when
substituting registers.

cmd/5c has the right approach: look at the opcode p->as to
decide the kind of register. It is unclear where 5g's copyau1
came from; perhaps it was an attempt to avoid expanding 5c's
a2type to include new instructions used only by 5g.

Copy a2type from cmd/5c, expand to include additional instructions,
and make it crash the compiler if asked about an instruction
it does not understand (avoid silent bugs in the future if new
instructions are added).

Should fix current arm build breakage.

While we're here, fix the print statements dumping the pred and
succ info in the asm listing to pass an int arg to %.4ud
(Prog.pc is a vlong now, due to the liblink merge).

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/62730043

Fixes #7294.

LGTM=minux.ma, dave, bradfitz
R=golang-codereviews, minux.ma, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/61370043

New testdata was created from existing using:
$ lipo gcc-386-darwin-exec gcc-amd64-darwin-exec -create -output fat-gcc-386-amd64-darwin-exec

Fixes #7250.

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

From the description of CL 60190043

debug/macho: Add support for opening fat/universal binaries.

New testdata was created from existing using:
$ lipo gcc-386-darwin-exec gcc-amd64-darwin-exec -create -output
fat-gcc-386-amd64-darwin-exec

Update #7250

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

So it doesn't bitrot.

Like the sha1 version (https://golang.org/cl/62270043)

LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/62420043

State of the world:

CL 46430043 introduced a new concurrent sweep but is broken.

CL 62360043 made the new sweep non-concurrent
to try to fix the world while we understand what's wrong with
the concurrent version.

This CL fixes the non-concurrent form to run finalizers.
This CL is just a band-aid to get the build green again.

Dmitriy is working on understanding and then fixing what's
wrong with the concurrent sweep.

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/62370043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/57680047

We see failures on builders, e.g.:
http://build.golang.org/log/70bb28cd6bcf8c4f49810a011bb4337a61977bf4

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

We now use the %A, %D, %P, and %R routines from liblink
across the board.

Fixes #7178.
Fixes #7055.

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

So it doesn't bitrot.

LGTM=agl
R=golang-codereviews, agl
CC=golang-codereviews
https://golang.org/cl/62270043

Better sampling of objects that are close in size to sampling rate.
See the comment for details.

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

Current "System->etext" is not very informative.
Add parent "GC" frame.
Replace un-unwindable syscall/cgo frames with Go stack that leads to the call.

LGTM=rsc
R=rsc, alex.brainman, ality
CC=golang-codereviews
https://golang.org/cl/61270043

(up to 2.8x).

This is a partially unrolled version which performs better for small
hashes and only sacrifices a small amount of ultimate speed to a fully
unrolled version which uses 5k of code.

Code size

  Before 1636 bytes
  After 1880 bytes
  15% larger

Benchmarks on Samsung Exynos 5 ARMv7 Chromebook

benchmark              old ns/op    new ns/op    delta
BenchmarkHash8Bytes         1907         1136  -40.43%
BenchmarkHash1K            20280         7547  -62.79%
BenchmarkHash8K           148469        52576  -64.59%

benchmark               old MB/s     new MB/s  speedup
BenchmarkHash8Bytes         4.19         7.04    1.68x
BenchmarkHash1K            50.49       135.68    2.69x
BenchmarkHash8K            55.18       155.81    2.82x

LGTM=dave, agl
R=dave, bradfitz, agl, adg, nick
CC=golang-codereviews
https://golang.org/cl/56990044

Remove GOOS_solaris ifdef from netpoll code,
instead introduce runtime edge/level triggered IO flag.
Replace armread/armwrite with a single arm(mode) function,
that's how all other interfaces look like and these functions
will need to do roughly the same thing anyway.

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

1. Make internal chan functions static.
2. Move selgen local variable instead of a member of G struct.
3. Change "bool *pres/selected" parameter of chansend/chanrecv to "bool block",
   which is simpler, faster and less code.
-37 lines total.

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

Moves sweep phase out of stoptheworld by adding
background sweeper goroutine and lazy on-demand sweeping.

It turned out to be somewhat trickier than I expected,
because there is no point in time when we know size of live heap
nor consistent number of mallocs and frees.
So everything related to next_gc, mprof, memstats, etc becomes trickier.

At the end of GC next_gc is conservatively set to heap_alloc*GOGC,
which is much larger than real value. But after every sweep
next_gc is decremented by freed*GOGC. So when everything is swept
next_gc becomes what it should be.

For mprof I had to introduce 3-generation scheme (allocs, revent_allocs, prev_allocs),
because by the end of GC we know number of frees for the *previous* GC.

Significant caution is required to not cross yet-unknown real value of next_gc.
This is achieved by 2 means:
1. Whenever I allocate a span from MCentral, I sweep a span in that MCentral.
2. Whenever I allocate N pages from MHeap, I sweep until at least N pages are
returned to heap.
This provides quite strong guarantees that heap does not grow when it should now.

http-1
allocated                    7036         7033      -0.04%
allocs                         60           60      +0.00%
cputime                     51050        46700      -8.52%
gc-pause-one             34060569      1777993     -94.78%
gc-pause-total               2554          133     -94.79%
latency-50                 178448       170926      -4.22%
latency-95                 284350       198294     -30.26%
latency-99                 345191       220652     -36.08%
rss                     101564416    101007360      -0.55%
sys-gc                    6606832      6541296      -0.99%
sys-heap                 88801280     87752704      -1.18%
sys-other                 7334208      7405928      +0.98%
sys-stack                  524288       524288      +0.00%
sys-total               103266608    102224216      -1.01%
time                        50339        46533      -7.56%
virtual-mem             292990976    293728256      +0.25%

garbage-1
allocated                 2983818      2990889      +0.24%
allocs                      62880        62902      +0.03%
cputime                  16480000     16190000      -1.76%
gc-pause-one            828462467    487875135     -41.11%
gc-pause-total            4142312      2439375     -41.11%
rss                    1151709184   1153712128      +0.17%
sys-gc                   66068352     66068352      +0.00%
sys-heap               1039728640   1039728640      +0.00%
sys-other                37776064     40770176      +7.93%
sys-stack                 8781824      8781824      +0.00%
sys-total              1152354880   1155348992      +0.26%
time                     16496998     16199876      -1.80%
virtual-mem            1409564672   1402281984      -0.52%

LGTM=rsc
R=golang-codereviews, sameer, rsc, iant, jeremyjackins, gobot
CC=golang-codereviews, khr
https://golang.org/cl/46430043

$ go test -cpu=1,1,1,1,1,1,1,1,1 encoding/json
--- FAIL: TestIndentBig (0.00 seconds)
        scanner_test.go:131: Indent(jsonBig) did not get bigger
On 4-th run initBig generates an empty array.

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

ConstantTimeCompare has always been documented to take equal length
slices but perhaps this is too subtle, even for 'subtle'.

Fixes #7304.

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

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

Allow clients to check for timeouts without relying on error substring
matching.

Fixes #6185.

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

Fixes #7104.

LGTM=iant
R=golang-dev, iant
CC=golang-codereviews
https://golang.org/cl/61480049

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/53410046

Fixes #7102.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/56770045

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

Second part of the solaris/amd64 linker changes: relocation and symbol table.

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

Fixes #7305.

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

The UNDEF instruction was listed in the instruction data as having the next instruction in the stream as its successor. This confused the optimizer into adding a load where it wasn't needed, in turn confusing the liveness analysis pass for GC bitmaps into thinking that the variable was live.

Fixes #7229.

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