Post-submit glitches caught by reviewers.

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

Once and for all.
Broken in cl/108640043.
I've messed it before. To test scavenger-related changes
one needs to alter the constants during final testing.
And then it's very easy to submit with the altered constants.

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

Deleted in cl/123700044.
I am not sure whether I need to restore it,
or delete rest of the uses...

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

Fixes #8261

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

Fixes #8576.

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

Before, a slice with cap=0 or a string with len=0 might have its
base pointer pointing beyond the actual slice/string data into
the next block. The collector had to ignore slices and strings with
cap=0 in order to avoid misinterpreting the base pointer.

Now, a slice with cap=0 or a string with len=0 still has a base
pointer pointing into the actual slice/string data, no matter what.
The collector can now always scan the pointer, which means
strings and slices are no longer special.

Fixes #8404.

LGTM=khr, josharian
R=josharian, khr, dvyukov
CC=golang-codereviews
https://golang.org/cl/112570044

Fixes test failure in build, probably a good idea anyway.

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

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

It was respected by unmarshal, but not marshal, so they didn't
round-trip.

Fixes #8582

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

Followup to CL 128700043.

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

A whole thread is too much for background scavenger that sleeps all the time anyway.
We already have sysmon thread that can do this work.
Also remove g->isbackground and simplify enter/exitsyscall.

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

Explain why it's safe to allocate chans with flagNoScan.

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

LGTM=rsc
R=golang-codereviews, ruiu, rsc, daniel.morsing
CC=golang-codereviews, khr
https://golang.org/cl/123700044

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

LGTM=0intro
R=0intro
CC=golang-codereviews
https://golang.org/cl/131190043

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

Normally, an expression of the form x.f or *y can be reordered
with function calls and communications.

Select is stricter than normal: each channel expression is evaluated
in source order. If you have case <-x.f and case <-foo(), then if the
evaluation of x.f causes a panic, foo must not have been called.
(This is in contrast to an expression like x.f + foo().)

Enforce this stricter ordering.

Fixes #8336.

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

Reduce duration of critical section,
make pcbuf local to function.

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

Part of cl/128670043 that got lost during submit.

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

And add a test.

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

benchmark                      old ns/op     new ns/op     delta
BenchmarkChanNonblocking       27.8          7.80          -71.94%
BenchmarkChanNonblocking-2     79.1          3.94          -95.02%
BenchmarkChanNonblocking-4     71.2          2.04          -97.13%

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

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

LGTM=khr
R=khr, remyoudompheng
CC=golang-codereviews
https://golang.org/cl/132820043

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

Update #8525

Some temporary variables that were fully registerized nevertheless had stack space allocated for them because the Addrs were still marked as having associated nodes.

Distribution of stack space reserved for temporary variables while running make.bash (6g):

BEFORE

40.89%  7026 allocauto: 0 to 0
 7.83%  1346 allocauto: 0 to 24
 7.22%  1241 allocauto: 0 to 8
 6.30%  1082 allocauto: 0 to 16
 4.96%   853 allocauto: 0 to 56
 4.59%   789 allocauto: 0 to 32
 2.97%   510 allocauto: 0 to 40
 2.32%   399 allocauto: 0 to 48
 2.10%   360 allocauto: 0 to 64
 1.91%   328 allocauto: 0 to 72

AFTER

48.49%  8332 allocauto: 0 to 0
 9.52%  1635 allocauto: 0 to 16
 5.28%   908 allocauto: 0 to 48
 4.80%   824 allocauto: 0 to 32
 4.73%   812 allocauto: 0 to 8
 3.38%   581 allocauto: 0 to 24
 2.35%   404 allocauto: 0 to 40
 2.32%   399 allocauto: 0 to 64
 1.65%   284 allocauto: 0 to 56
 1.34%   230 allocauto: 0 to 72

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

TBR=dfc
CC=golang-codereviews
https://golang.org/cl/126210047

cmd/6g has been doing this for a long time.

Arrays are still problematic on 5g because the addressing
for t[0] where local var t has type [3]uintptr takes the address of t.
That's issue 8125.

Fixes #8123.

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

CL 130240043 did this but broke ARM, because
it made newErrorCString start allocating, so we rolled
it back in CL 133810043.

CL 133820043 removed that allocation.

Try again.

Fixes #8405.

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

Fixes #8494.

LGTM=rsc
R=golang-codereviews, gobot, rsc, evankroske
CC=golang-codereviews
https://golang.org/cl/123040043

Now 'go vet runtime' only shows:

        malloc.go:200: possible misuse of unsafe.Pointer
        malloc.go:214: possible misuse of unsafe.Pointer
        malloc.go:250: possible misuse of unsafe.Pointer
        stubs.go:167: possible misuse of unsafe.Pointer

Those are all unavoidable.

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

It now serves as an example for go generate as well as for yacc.

NOTE: Depends on go generate, which is not yet checked in.
This is a proof of concept of the approach.
That is https://golang.org/cl/125580044.

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

First cut.

Works well enough to support yacc via
        https://golang.org/cl/125620044.

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

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

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

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

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

This is based on the crash dump provided by Alan
and on mental experiments:

sweep 0 74
fatal error: gc: unswept span
runtime stack:
runtime.throw(0x9df60d)
markroot(0xc208002000, 0x3)
runtime.parfordo(0xc208002000)
runtime.gchelper()

I think that when we moved all stacks into heap,
we introduced a bunch of bad data races. This was later
worsened by parallel stack shrinking.

Observation 1: exitsyscall can allocate a stack from heap at any time (including during STW).
Observation 2: parallel stack shrinking can (surprisingly) grow heap during marking.
Consider that we steadily grow stacks of a number of goroutines from 8K to 16K.
And during GC they all can be shrunk back to 8K. Shrinking will allocate lots of 8K
stacks, and we do not necessary have that many in heap at this moment. So shrinking
can grow heap as well.

Consequence: any access to mheap.allspans in GC (and otherwise) must take heap lock.
This is not true in several places.

Fix this by protecting accesses to mheap.allspans and introducing allspans cache for marking,
similar to what we use for sweeping.

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

Cache unrolled GC bitmask for types up to 64/32K on 64/32-bit systems,
this corresponds to up to 4K cached bitmask.
Perf builders say that 2% of time is spent in unrollgcproginplace_m/unrollgcprog1
on http benchmark:
http://goperfd.appspot.com/log/f42045f45bf61a0da53b724a7c8567824a0ad6c9

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

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

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