This removes a major unsafe thorn in our side, a perennial obstacle
to clean garbage collection.
Not coincidentally: In cleaning this up, several bugs were found,
including code that reached inside by-value interfaces to create
pointers for pointer-receiver methods. Unsafe code is just as
advertised.

Performance of course suffers, but not too badly. The Pipe number
is more indicative, since it's doing I/O that simulates a network
connection. Plus these are end-to-end, so each end suffers
only half of this pain.

The edit is pretty much a line-by-line conversion, with a few
simplifications and a couple of new tests. There may be more
performance to gain.

BenchmarkEndToEndByteBuffer     2493          3033          +21.66%
BenchmarkEndToEndPipe           4953          5597          +13.00%

Fixes #5159.

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

Fix copy paste error pointed out by rsc, https://golang.org/cl/107290043/diff/60001/test/fixedbugs/issue8074.go#newcode7

LGTM=ruiu, r
R=golang-codereviews, ruiu, r
CC=golang-codereviews
https://golang.org/cl/106210047

Fixes #8299.

R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/103640044

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

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

The only text that describes the accepted format is in the package doc,
which is far away from these functions. The other flag types don't need
this explicitness because they are more obvious.

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

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

Remove GC bitmap backward scanning.
This was already done once in https://golang.org/cl/5530074/
Still makes GC a bit faster.
On the garbage benchmark, before:
        gc-pause-one=237345195
        gc-pause-total=4746903
        cputime=32427775
        time=32458208
after:
        gc-pause-one=235484019
        gc-pause-total=4709680
        cputime=31861965
        time=31877772
Also prepares mgc0.c for future changes.

R=golang-codereviews, khr, khr
CC=golang-codereviews, rsc
https://golang.org/cl/105380043

newproc takes two extra pointers, not two extra registers.
On amd64p32 (nacl) they are different.

We diagnosed this before the 1.3 cut but the tree was frozen.
I believe this is causing the random problems on the builder.

Fixes #8199.

TBR=r
CC=golang-codereviews
https://golang.org/cl/102710043

Include these files in the build,
even though they don't get executed.

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

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

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

Output number of spinning threads,
this is useful to understanding whether the scheduler
is in a steady state or not.

R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/103540045

LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/108150043

Say when a goroutine is locked to OS thread in crash reports
and goroutine profiles.
It can be useful to understand what goroutines consume OS threads
(syscall and locked), e.g. if you forget to call UnlockOSThread
or leak locked goroutines.

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

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

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

Pending acceptance of CL 101500044
and adjustment of test/fixedbugs/bug299.go.

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

The runtime has historically held two dedicated values g (current goroutine)
and m (current thread) in 'extern register' slots (TLS on x86, real registers
backed by TLS on ARM).

This CL removes the extern register m; code now uses g->m.

On ARM, this frees up the register that formerly held m (R9).
This is important for NaCl, because NaCl ARM code cannot use R9 at all.

The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected:

BenchmarkBinaryTree17              5491374955     5471024381     -0.37%
BenchmarkFannkuch11                4357101311     4275174828     -1.88%
BenchmarkGobDecode                 11029957       11364184       +3.03%
BenchmarkGobEncode                 6852205        6784822        -0.98%
BenchmarkGzip                      650795967      650152275      -0.10%
BenchmarkGunzip                    140962363      141041670      +0.06%
BenchmarkHTTPClientServer          71581          73081          +2.10%
BenchmarkJSONEncode                31928079       31913356       -0.05%
BenchmarkJSONDecode                117470065      113689916      -3.22%
BenchmarkMandelbrot200             6008923        5998712        -0.17%
BenchmarkGoParse                   6310917        6327487        +0.26%
BenchmarkRegexpMatchMedium_1K      114568         114763         +0.17%
BenchmarkRegexpMatchHard_1K        168977         169244         +0.16%
BenchmarkRevcomp                   935294971      914060918      -2.27%
BenchmarkTemplate                  145917123      148186096      +1.55%

Minux previous reported larger variations, but these were caused by
run-to-run noise, not repeatable slowdowns.

Actual code changes by Minux.
I only did the docs and the benchmarking.

LGTM=dvyukov, iant, minux
R=minux, josharian, iant, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/109050043

Matches CL 101500044.

LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/110160044

A single iteration of BenchmarkSaveRestore runs for 5 seconds
on my freebsd machine. 5 seconds looks like too long for a single
iteration.
This is the only benchmark that times out on freebsd-amd64-race builder.

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

Breaks the build

««« original CL description
cmd/go: build test files containing non-runnable examples

Even if we can't run them, we should at least check that they compile.

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

TBR=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/110140044

Runs for 4 seconds on my mac.
Also this is the only test that times out on freebsd in -race mode.

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

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

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

This CL removes the special syntax for method receivers and
makes it just like other parameters. Instead, the crucial
receiver-specific rules (exactly one receiver, receiver type
must be of the form T or *T) are specified verbally instead
of syntactically.

This is a fully backward-compatible (and minor) syntax
relaxation. As a result, the following syntactic restrictions
(which are completely irrelevant) and which were only in place
for receivers are removed:

a) receiver types cannot be parenthesized
b) receiver parameter lists cannot have a trailing comma

The result of this CL is a simplication of the spec and the
implementation, with no impact on existing (or future) code.

Noteworthy:

- gc already permits a trailing comma at the end of a receiver
  declaration:

  func (recv T,) m() {}

  This is technically a bug with the current spec; this CL will
  legalize this notation.

- gccgo produces a misleading error when a trailing comma is used:

  error: method has multiple receivers

  (even though there's only one receiver)

- Compilers and type-checkers won't need to report errors anymore
  if receiver types are parenthesized.

Fixes #4496.

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

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

Even if we can't run them, we should at least check that they compile.

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

Fixes #8218.

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

Update #8266

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

For work on goauth2.

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

R=gri
CC=golang-codereviews
https://golang.org/cl/104340043

This CL re-applies the tests added in CL 101330053 and subsequently rolled back in CL 102610043.

The original author of this change was Rui Ueyama <ruiu@google.com>

LGTM=r, ruiu
R=ruiu, r
CC=golang-codereviews
https://golang.org/cl/109170043

The number of estimated iterations required to reach the benchtime is multiplied by a safety margin (to avoid falling just short) and then rounded up to a readable number. With an accurate estimate, in the worse case, the resulting number of iterations could be 3.75x more than necessary: 1.5x for safety * 2.5x to round up (e.g. from 2eX+1 to 5eX).

This CL reduces the safety margin to 1.2x. Experimentation showed a diminishing margin of return past 1.2x, although the average case continued to show improvements down to 1.05x.

This CL also reduces the maximum round-up multiplier from 2.5x (from 2eX+1 to 5eX) to 2x, by allowing the number of iterations to be of the form 3eX.

Both changes improve benchmark wall clock times, and the effects are cumulative.

From 1.5x to 1.2x safety margin:

package		old s	new s	delta
bytes		163	125	-23%
encoding/json	27	21	-22%
net/http	42	36	-14%
runtime		463	418	-10%
strings		82	65	-21%

Allowing 3eX iterations:

package		old s	new s	delta
bytes		163	134	-18%
encoding/json	27	23	-15%
net/http	42	36	-14%
runtime		463	422	-9%
strings		82	72	-12%

Combined:

package		old s	new s	delta
bytes		163	112	-31%
encoding/json	27	20	-26%
net/http	42	30	-29%
runtime		463	346	-25%
strings		82	60	-27%

LGTM=crawshaw, r, rsc
R=golang-codereviews, crawshaw, r, rsc
CC=golang-codereviews
https://golang.org/cl/105990045

The previous call to parseRange already checks whether
all the ranges start before the end of file.

LGTM=robert.hencke, bradfitz
R=golang-codereviews, robert.hencke, gobot, bradfitz
CC=golang-codereviews
https://golang.org/cl/91880044

Updates z-files from 10.7 kernel-based to 10.9 kernel-based.

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

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

Update #1435

This proposal disables Setuid and Setgid on all linux platforms.

Issue 1435 has been open for a long time, and it is unlikely to be addressed soon so an argument was made by a commenter

https://code.google.com/p/go/issues/detail?id=1435#c45

That these functions should made to fail rather than succeed in their broken state.

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

Update #8266

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

MOV with SSE registers seems faster than REP MOVSQ if the
size being copied is less than about 2K. Previously we
didn't use MOV if the memory region is larger than 256
byte. This patch improves the performance of 257 ~ 2048
byte non-overlapping copy by using MOV.

Here is the benchmark result on Intel Xeon 3.5GHz (Nehalem).

benchmark               old ns/op    new ns/op    delta
BenchmarkMemmove16              4            4   +0.42%
BenchmarkMemmove32              5            5   -0.20%
BenchmarkMemmove64              6            6   -0.81%
BenchmarkMemmove128             7            7   -0.82%
BenchmarkMemmove256            10           10   +1.92%
BenchmarkMemmove512            29           16  -44.90%
BenchmarkMemmove1024           37           25  -31.55%
BenchmarkMemmove2048           55           44  -19.46%
BenchmarkMemmove4096           92           91   -0.76%

benchmark                old MB/s     new MB/s  speedup
BenchmarkMemmove16        3370.61      3356.88    1.00x
BenchmarkMemmove32        6368.68      6386.99    1.00x
BenchmarkMemmove64       10367.37     10462.62    1.01x
BenchmarkMemmove128      17551.16     17713.48    1.01x
BenchmarkMemmove256      24692.81     24142.99    0.98x
BenchmarkMemmove512      17428.70     31687.72    1.82x
BenchmarkMemmove1024     27401.82     40009.45    1.46x
BenchmarkMemmove2048     36884.86     45766.98    1.24x
BenchmarkMemmove4096     44295.91     44627.86    1.01x

LGTM=khr
R=golang-codereviews, gobot, khr
CC=golang-codereviews
https://golang.org/cl/90500043