[release-branch.go1.4] go1.4.3

Change-Id: I9f0c6cf2dfc83f95905e75977a3e679a4152aa41
Reviewed-on: https://go-review.googlesource.com/14855
Run-TryBot: Chris Broadfoot <[email protected]>
Reviewed-by: Chris Broadfoot <[email protected]>

[release-branch.go1.5] go1.5.1

Change-Id: I98d9fefd923e2a35031385045382ba372f1d614a
Reviewed-on: https://go-review.googlesource.com/14401
Reviewed-by: Andrew Gerrand <[email protected]>

[release-branch.go1.5] go1.5

This updates the VERSION file.
The release proper has not happened yet.

Change-Id: I3e33b5f95aede0da8ca1aef0d9c381942873c9a8
Reviewed-on: https://go-review.googlesource.com/13702
Reviewed-by: Rob Pike <[email protected]>

[release-branch.go1.5] cmd/newlink: remove from release branch

Change-Id: Iad86bde6f2e0482745a4000ec4e192ade352983b
Reviewed-on: https://go-review.googlesource.com/13292
Reviewed-by: Russ Cox <[email protected]>
Run-TryBot: Andrew Gerrand <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>

runtime: set invalidptr=1 by default, as documented

Also make invalidptr control the recently added GC pointer check,
as documented.

Change-Id: Iccfdf49480219d12be8b33b8f03d8312d8ceabed
Reviewed-on: https://go-review.googlesource.com/12857
Run-TryBot: Russ Cox <[email protected]>
Reviewed-by: Rob Pike <[email protected]>

runtime: don't free large spans until heapBitsSweepSpan returns

This fixes a race between 1) sweeping and freeing an unmarked large
span and 2) reusing that span and allocating from it. This race arises
because mSpan_Sweep returns spans for large objects to the heap
*before* heapBitsSweepSpan clears the mark bit on the object in the
span.

Specifically, the following sequence of events can lead to an
incorrectly zeroed bitmap byte, which causes the garbage collector to
not trace any pointers in that object (the pointer bits for the first
four words are cleared, and the scan bits are also cleared, so it
looks like a no-scan object).

1) P0 calls mSpan_Sweep on a large span S0 with an unmarked object on it.

2) mSpan_Sweep calls heapBitsSweepSpan, which invokes the callback for
   the one (unmarked) object on the span.

3) The callback calls mHeap_Free, which makes span S0 available for
   allocation, but this is too early.

4) P1 grabs this S0 from the heap to use for allocation.

5) P1 allocates an object on this span and writes that object's type
   bits to the bitmap.

6) P0 returns from the callback to heapBitsSweepSpan.
   heapBitsSweepSpan clears the byte containing the mark, even though
   this span is now owned by P1 and this byte contains important
   bitmap information.

This fixes this problem by simply delaying the mHeap_Free until after
the heapBitsSweepSpan. I think the overall logic of mSpan_Sweep could
be simplified now, but this seems like the minimal change.

Fixes golang#11617.

Change-Id: I6b1382c7e7cc35f81984467c0772fe9848b7522a
Reviewed-on: https://go-review.googlesource.com/12320
Run-TryBot: Austin Clements <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Matthew Dempsky <[email protected]>
Reviewed-by: Rob Pike <[email protected]>

cmd/go: disable vendoredImportPath for code outside $GOPATH

It was crashing.
This fixes the build for
GO15VENDOREXPERIMENT=1 go test -short runtime

Fixes golang#11416.

Change-Id: I74a9114cdd8ebafcc9d2a6f40bf500db19c6e825
Reviewed-on: https://go-review.googlesource.com/11964
Reviewed-by: Russ Cox <[email protected]>

[release-branch.go1.4] go1.4.2

Change-Id: I0f198e4a94c50a11228c15d6aaac0cea890b5b58
Reviewed-on: https://go-review.googlesource.com/5111
Reviewed-by: Rob Pike <[email protected]>

[release-branch.go1.4] go1.4.1

Change-Id: If275a5caa07cfd16b7052ad50709e1d0f1258223
Reviewed-on: https://go-review.googlesource.com/2856
Reviewed-by: Rob Pike <[email protected]>

go1.4

LGTM=bradfitz, minux, dsymonds
R=rsc, bradfitz, iant, dsymonds, minux
CC=golang-codereviews
https://golang.org/cl/188920043