runtime: add timing test for iterate/delete map idiom.

LGTM=bradfitz, iant
R=iant, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/140510043
net: fix inconsistent behavior across platforms in SetKeepAlivePeriod

The previous implementation used per-socket TCP keepalive options
wrong. For example, it used another level socket option to control
TCP and it didn't use TCP_KEEPINTVL option when possible.

Fixes issue 8683.
Fixes issue 8701.
Update issue 8679

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/136480043
runtime: allow crash from gsignal stack

The uses of onM in dopanic/startpanic are okay even from the signal stack.

Fixes issue 8666.

LGTM=khr
R=khr
CC=golang-codereviews
https://codereview.appspot.com/134710043
cmd/gc: emit write barriers

A write *p = x that needs a write barrier (not all do)
now turns into runtime.writebarrierptr(p, x)
or one of the other variants.

The write barrier implementations are trivial.
The goal here is to emit the calls in the correct places
and to incur the cost of those function calls in the Go 1.4 cycle.

Performance on the Go 1 benchmark suite below.
Remember, the goal is to slow things down (and be correct).

We will look into optimizations in separate CLs, as part of
the process of comparing Go 1.3 against tip in order to make
sure Go 1.4 runs at least as fast as Go 1.3.

benchmark                          old ns/op      new ns/op      delta
BenchmarkBinaryTree17              3118336716     3452876110     +10.73%
BenchmarkFannkuch11                3184497677     3211552284     +0.85%
BenchmarkFmtFprintfEmpty           89.9           107            +19.02%
BenchmarkFmtFprintfString          236            287            +21.61%
BenchmarkFmtFprintfInt             246            278            +13.01%
BenchmarkFmtFprintfIntInt          395            458            +15.95%
BenchmarkFmtFprintfPrefixedInt     343            378            +10.20%
BenchmarkFmtFprintfFloat           477            525            +10.06%
BenchmarkFmtManyArgs               1446           1707           +18.05%
BenchmarkGobDecode                 14398047       14685958       +2.00%
BenchmarkGobEncode                 12557718       12947104       +3.10%
BenchmarkGzip                      453462345      472413285      +4.18%
BenchmarkGunzip                    114226016      115127398      +0.79%
BenchmarkHTTPClientServer          114689         112122         -2.24%
BenchmarkJSONEncode                24914536       26135942       +4.90%
BenchmarkJSONDecode                86832877       103620289      +19.33%
BenchmarkMandelbrot200             4833452        4898780        +1.35%
BenchmarkGoParse                   4317976        4835474        +11.98%
BenchmarkRegexpMatchEasy0_32       150            166            +10.67%
BenchmarkRegexpMatchEasy0_1K       393            402            +2.29%
BenchmarkRegexpMatchEasy1_32       125            142            +13.60%
BenchmarkRegexpMatchEasy1_1K       1010           1236           +22.38%
BenchmarkRegexpMatchMedium_32      232            301            +29.74%
BenchmarkRegexpMatchMedium_1K      76963          102721         +33.47%
BenchmarkRegexpMatchHard_32        3833           5463           +42.53%
BenchmarkRegexpMatchHard_1K        119668         161614         +35.05%
BenchmarkRevcomp                   763449047      706768534      -7.42%
BenchmarkTemplate                  124954724      134834549      +7.91%
BenchmarkTimeParse                 517            511            -1.16%
BenchmarkTimeFormat                501            514            +2.59%

benchmark                         old MB/s     new MB/s     speedup
BenchmarkGobDecode                53.31        52.26        0.98x
BenchmarkGobEncode                61.12        59.28        0.97x
BenchmarkGzip                     42.79        41.08        0.96x
BenchmarkGunzip                   169.88       168.55       0.99x
BenchmarkJSONEncode               77.89        74.25        0.95x
BenchmarkJSONDecode               22.35        18.73        0.84x
BenchmarkGoParse                  13.41        11.98        0.89x
BenchmarkRegexpMatchEasy0_32      213.30       191.72       0.90x
BenchmarkRegexpMatchEasy0_1K      2603.92      2542.74      0.98x
BenchmarkRegexpMatchEasy1_32      254.00       224.93       0.89x
BenchmarkRegexpMatchEasy1_1K      1013.53      827.98       0.82x
BenchmarkRegexpMatchMedium_32     4.30         3.31         0.77x
BenchmarkRegexpMatchMedium_1K     13.30        9.97         0.75x
BenchmarkRegexpMatchHard_32       8.35         5.86         0.70x
BenchmarkRegexpMatchHard_1K       8.56         6.34         0.74x
BenchmarkRevcomp                  332.92       359.62       1.08x
BenchmarkTemplate                 15.53        14.39        0.93x

LGTM=rlh
R=rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://codereview.appspot.com/136380043
test: return errors earlier in run.go

Fixes issue 8184.

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://codereview.appspot.com/137510043
go/printer, gofmt: don't align map entries for irregular inputs

Details: Until now, when we saw a key:value pair that fit onto
a single line, we assumed that it should be formatted with a
vtab after the ':' for alignment of its value. This leads to
odd behavior if there are more than one such pair on a line.
This CL changes the behavior such that alignment is only used
for the first pair on a line. This preserves existing behavior
(in the std lib we have composite literals where the last line
contains multiple entries and the first entry's value is aligned
with the values on previous lines), and resolves this issue.

No impact on formatting of std lib, go.tools, go.exp, go.net.

Fixes issue 8685.

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://codereview.appspot.com/139430043
runtime: move gosched to Go, to add stack frame information

LGTM=khr
R=khr
CC=golang-codereviews
https://codereview.appspot.com/134520044
runtime: make Gosched nosplit

Replacing gosched with Gosched broke some builds because
some of the call sites are at times when the stack cannot be grown.

TBR=khr
CC=golang-codereviews
https://codereview.appspot.com/142000043
runtime: get rid of copyable check - all G frames are copyable.

Just go ahead and do it, if something is wrong we'll throw.

Also rip out cc-generated arg ptr maps, they are useless now.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/133690045
doc: link directly to https://golang.org/dl/

Fixes issue 8705.

LGTM=adg
R=golang-codereviews, bradfitz, adg
CC=golang-codereviews
https://codereview.appspot.com/142890044

Committer: Andrew Gerrand <adg@golang.org>
runtime: make gostringnocopy update maxstring

Fixes issue 8706

LGTM=josharian
R=josharian
CC=golang-codereviews
https://codereview.appspot.com/143880043
A+C: Michael MacInnis (individual CLA)

Generated by a+c.

R=gobot
CC=golang-codereviews
https://codereview.appspot.com/140570043
syscall: SysProcAttr job control changes

Making the child's process group the foreground process group and
placing the child in a specific process group involves co-ordination
between the parent and child that must be done post-fork but pre-exec.

LGTM=iant
R=golang-codereviews, gobot, iant, mikioh.mikioh
CC=golang-codereviews
https://codereview.appspot.com/131750044

Committer: Ian Lance Taylor <iant@golang.org>
runtime: fix cgo to handle the case where the G stack is copied.

Tests will come in a separate CL after the funcdata stuff is resolved.

Update issue 8696

LGTM=iant, rsc
R=rsc, iant
CC=golang-codereviews
https://codereview.appspot.com/138330045
cmd/gc: turn Go prototypes into ptr liveness maps for assembly functions

The goal here is to allow assembly functions to appear in the middle
of a Go stack (having called other code) and still record enough information
about their pointers so that stack copying and garbage collection can handle
them precisely. Today, these frames are handled only conservatively.

If you write

        func myfunc(x *float64) (y *int)

(with no body, an 'extern' declaration), then the Go compiler now emits
a liveness bitmap for use from the assembly definition of myfunc.
The bitmap symbol is myfunc.args_stackmap and it contains two bitmaps.
The first bitmap, in effect at function entry, marks all inputs as live.
The second bitmap, not in effect at function entry, marks the outputs
live as well.

In funcdata.h, define new assembly macros:

GO_ARGS opts in to using the Go compiler-generated liveness bitmap
for the current function.

GO_RESULTS_INITIALIZED indicates that the results have been initialized
and need to be kept live for the remainder of the function; it causes a
switch to the second generated bitmap for the assembly code that follows.

NO_LOCAL_POINTERS indicates that there are no pointers in the
local variables being stored in the function's stack frame.

LGTM=khr
R=khr
CC=golang-codereviews
https://codereview.appspot.com/137520043
syscall: make func Syscall use pointer maps from Go prototypes

Before, Syscall and friends were having their arguments
treated conservatively. Now they will use the Go prototype,
which will mean the arguments are not considered pointers
at all.

This is safe because of CL 139360044.

The fact that all these non-Solaris systems were using
conservative scanning of the Syscall arguments is why
the failure that prompted CL 139360044 was only
observed on Solaris, which does something completely different.
If we'd done this earlier, we'd have seen the Solaris
failure in more places.

LGTM=khr
R=khr
CC=golang-codereviews
https://codereview.appspot.com/144730043
syscall: add #include "funcdata.h" to files modified in last CL

That's what defines GO_ARGS.

TBR=khr
CC=golang-codereviews
https://codereview.appspot.com/141460043
runtime: save correct pid for new m's on plan9/amd64

The pid field in the Tos structure is a 32-bit value.
Loading a 64-bit word also brings in the next field
which is used for the profiling clock.

LGTM=0intro, aram
R=rsc, 0intro, aram
CC=golang-codereviews, mischief
https://codereview.appspot.com/139560044
runtime: look up arg stackmap for makeFuncStub/methodValueStub during traceback

makeFuncStub and methodValueStub are used by reflect as
generic function implementations. Each call might have
different arguments. Extract those arguments from the
closure data instead of assuming it is the same each time.

Because the argument map is now being extracted from the
function itself, we don't need the special cases in reflect.Call
anymore, so delete those.

Fixes an occasional crash seen when stack copying does
not update makeFuncStub's arguments correctly.

Will also help make it safe to require stack maps in the
garbage collector.

Derived from CL 142000044 by khr.

LGTM=khr
R=khr
CC=golang-codereviews
https://codereview.appspot.com/143890044
runtime: tell the truth about BitVector type

Dmitriy changed all the execution to interpret the BitVector
as an array of bytes. Update the declaration and generation
of the bitmaps to match, to avoid problems on big-endian
machines.

LGTM=khr
R=khr
CC=dvyukov, golang-codereviews
https://codereview.appspot.com/140570044