Generated by a+c.

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

Generated by a+c.

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

A TLS slot is reserved by _rt0_.*_plan9 as an automatic and
its address (which is static on Plan 9) is saved in the
global _privates symbol. The startup linkage now is exactly
like that from Plan 9 libc, and the way we access g is
exactly as if we'd have used privalloc(2).

Aside from making the code more standard, this change
drastically simplifies it, both for 386 and for amd64, and
makes the Plan 9 code in liblink common for both 386 and
amd64.

The amd64 runtime code was cleared of nxm assumptions, and
now runs on the standard Plan 9 kernel.

Note handling fixes will follow in a separate CL.

LGTM=rsc
R=golang-codereviews, rsc, bradfitz, dave
CC=0intro, ality, golang-codereviews, jas, minux.ma, mischief
https://golang.org/cl/101510049

We restored registers correctly in the usual case where the thread
is a Go-managed thread and called runtime·sighandler, but we
failed to do so when runtime·sigtramp was called on a cgo-created
thread. In that case, runtime·sigtramp called runtime·badsignal,
a Go function, and did not restore registers after it returned

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

On amd64, the real time is reduced from 176.76s to 140.26s.
On ARM, the real time is reduced from 921.61s to 726.30s.

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

As android and linux have significant overlap, and
because build tags are a poor way to represent an
OS target, this CL introduces an exception into
go/build: linux is treated as a synonym for android
when matching files.

http://golang.org/s/go14android
https://groups.google.com/forum/#!topic/golang-dev/P1ATVp1mun0

LGTM=rsc, minux
R=golang-codereviews, mikioh.mikioh, dave, aram, minux, gobot, rsc, aram.h, elias.naur, iant
CC=golang-codereviews, rsc
https://golang.org/cl/105270043

Move decAlloc calls a bit higher in the call tree.
Cleans code marginally, improves speed marginally.
The benchmarks are noisy but the median time from
20 consective 1-second runs improves by about 2%.

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

3-index slices of the form s[:len(s):len(s)]
cannot be simplified to s[::len(s)].

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

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

Fixes #7631.

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

Generated by a+c.

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

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

CC=golang-codereviews
https://golang.org/cl/101590043

We are not the right people to support editor plugins, and the profusion
of editors in this CL demonstrates the unreality of pretending to do so.
People are free to create and advertise their own repos with support.

For discussion: https://groups.google.com/forum/#!topic/golang-dev/SA7fD470FxU

LGTM=rminnich, kamil.kisiel, gri, rsc, dave, josharian, ruiu
R=golang-codereviews, rminnich, kamil.kisiel, gri, rsc, dominik.honnef, dave, josharian, ruiu, ajstarks
CC=golang-codereviews
https://golang.org/cl/105470043

There is no reason to generate different code for cap and len.

Fixes #8025.
Fixes #8026.

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

Breaks windows and race detector.
TBR=rsc

««« original CL description
runtime: stack allocator, separate from mallocgc

In order to move malloc to Go, we need to have a
separate stack allocator.  If we run out of stack
during malloc, malloc will not be available
to allocate a new stack.

Stacks are the last remaining FlagNoGC objects in the
GC heap.  Once they are out, we can get rid of the
distinction between the allocated/blockboundary bits.
(This will be in a separate change.)

Fixes #7468
Fixes #7424

LGTM=rsc, dvyukov
R=golang-codereviews, dvyukov, khr, dave, rsc
CC=golang-codereviews
https://golang.org/cl/104200047
»»»

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

In order to move malloc to Go, we need to have a
separate stack allocator.  If we run out of stack
during malloc, malloc will not be available
to allocate a new stack.

Stacks are the last remaining FlagNoGC objects in the
GC heap.  Once they are out, we can get rid of the
distinction between the allocated/blockboundary bits.
(This will be in a separate change.)

Fixes #7468
Fixes #7424

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

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

The old code's structure needed to track indirections because of the
use of unsafe. That is no longer necessary, so we can remove all
that tracking. The code cleans up considerably but is a little slower.
We may be able to recover that performance drop. I believe the
code quality improvement is worthwhile regardless.

BenchmarkEndToEndPipe           5610          5780          +3.03%
BenchmarkEndToEndByteBuffer     3156          3222          +2.09%

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

If the actual types of two reflect values are
the same and the values are structs, they must
have the same number of fields.

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

CC=golang-codereviews
https://golang.org/cl/103690043

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