Fixes #13881.

Change-Id: Idff77db381640184ddd2b65022133bb226168800
Reviewed-on: https://go-review.googlesource.com/18449Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

Currently, due to an oversight, we only balance work buffers
in background and idle workers and not in assists. As a
result, in assist-heavy workloads, assists are likely to tie
up large work buffers in per-P caches increasing the
likelihood that the global list will be empty. This increases
the likelihood that other GC workers will exit and assists
will block, slowing down the system as a whole. Fix this by
eagerly balancing work buffers as soon as the assists notice
that the global buffers are empty. This makes it much more
likely that work will be immediately available to other
workers and assists.

This change reduces the garbage benchmark time by 39% and
fixes the regresssion seen at CL 15893 golang.org/cl/15893.

Garbage benchmark times before and after this CL.
Before GOPERF-METRIC:time=4427020
After  GOPERF-METRIC:time=2721645

Fixes #13827

Change-Id: I9cb531fb873bab4b69ce9c1617e30df6c49cdcfe
Reviewed-on: https://go-review.googlesource.com/18341Reviewed-by: Austin Clements <austin@google.com>

This change documents the behaviour change caused by
https://go-review.googlesource.com/18480 in Go 1.6.

Updates #13886

Change-Id: I2daa08a62775bbc209f0f4cbeae21b8184ce7609
Reviewed-on: https://go-review.googlesource.com/18481Reviewed-by: Russ Cox <rsc@golang.org>

The AESNI GCM code decrypts and authenticates concurrently and so
overwrites the destination buffer even in the case of an authentication
failure.

This change updates the documentation to make that clear and also
mimics that behaviour in the generic code so that different platforms
act identically.

Fixes #13886

Change-Id: Idc54e51f01e27b0fc60c1745d50bb4c099d37e94
Reviewed-on: https://go-review.googlesource.com/18480Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

mips64 builder and one machine of the mips64le builder has small amount
of memory. Since CL 18199, they have been running slowly, as more
processes were launched in running 'test' directory, and a lot of swap
were used. This CL brings all.bash from 5h back to 3h on Loongson 2E
with 512 MB memory.

Change-Id: I4a22e239a542a99ba5986753205d8cd1f4b3d3c6
Reviewed-on: https://go-review.googlesource.com/18483Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates http2 to x/net git rev 0e6d34ef942 for https://golang.org/cl/18472
which means we'll get to delete a ton of grpc-go code and just use the
standard library's HTTP client instead.

Also, the comments in this CL aren't entirely accurate it turns out.
RFC 2616 says:

"The Trailer header field can be used to indicate which header fields
are included in a trailer (see section 14.40)."

And 14.40:

"  An HTTP/1.1 message SHOULD include a Trailer header field in a
   message using chunked transfer-coding with a non-empty trailer. Doing
   so allows the recipient to know which header fields to expect in the
   trailer.

   If no Trailer header field is present, the trailer SHOULD NOT include
   any header fields. See section 3.6.1 for restrictions on the use of
   trailer fields in a "chunked" transfer-coding."

So it's really a SHOULD more than a MUST.

And gRPC (at least Google's server) doesn't predeclare "grpc-status"
ahead of time in a Trailer Header, so we'll be lenient. We were too
strict anyway. It's also not a concern for the Go client we have a
different place to populate the Trailers, and it won't confuse clients
which aren't looking for them. The ResponseWriter server side is more
complicated (and strict), though, since we don't want to widen the
ResponseWriter interface. So the Go server still requires that you
predeclare Trailers.

Change-Id: Ia2defc11a2469fb8570ecfabb8453537121084eb
Reviewed-on: https://go-review.googlesource.com/18473
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #13893

Change-Id: I2577b38fdb19299227dc146f707cf9df663dcdfc
Reviewed-on: https://go-review.googlesource.com/18471
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I08d77d52b68b062c2eb1901fcfca34d45a210cce
Reviewed-on: https://go-review.googlesource.com/18142Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Ia6d40ead1e54dd0b8998370cbabc2d7cd8b7aa0b
Reviewed-on: https://go-review.googlesource.com/18470Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I95c6c85eecb53ffe52b64d521180148b624e9424
Reviewed-on: https://go-review.googlesource.com/18423Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The previous behaviour of installing the signal handlers in a separate
thread meant that Go initialization raced with non-Go initialization if
the non-Go initialization also wanted to install signal handlers.  Make
installing signal handlers synchronous so that the process-wide behavior
is predictable.

Update #9896.

Change-Id: Ice24299877ec46f8518b072a381932d273096a32
Reviewed-on: https://go-review.googlesource.com/18150
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

TBR adonovan

Fixes #13882.

Change-Id: I8664669f5d6adfec6f16e154263b1f0ea8988175
Reviewed-on: https://go-review.googlesource.com/18445Reviewed-by: Robert Griesemer <gri@golang.org>

Go 1.6 simplified the GC phases. The "synchronize Ps" phase no longer
exists and "root scan" and "mark" phases have been combined.

Update the gctrace line implementation and documentation to remove the
unused phases.

Fixes #13536.

Change-Id: I4fc37a3ce1ae3a99d48c0be2df64cbda3e05dee6
Reviewed-on: https://go-review.googlesource.com/18458
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13688.

Change-Id: I53363aeeeba4560211d56d4571a8e058d5dbbd8a
Reviewed-on: https://go-review.googlesource.com/18308Reviewed-by: Alan Donovan <adonovan@google.com>

Sigh. Sleeps on FreeBSD also yield the rest of the time slice and
profiling signals are only delivered when a process completes a time
slice (worse, itimer time is only accounted to the process that
completes a time slice). It's less noticeable than the other BSDs
because the default tick rate is 1000Hz, but it's still failing
regularly.

Fixes #13846.

Change-Id: I41bf116bffe46682433b677183f86944d0944ed4
Reviewed-on: https://go-review.googlesource.com/18455Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Austin Clements <austin@google.com>

Change-Id: Ib838d2b98e3f84ffd240849817cafc69415ba74e
Reviewed-on: https://go-review.googlesource.com/18376Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #13875.

Change-Id: Icbb85c858d0bc545499a2b31622e9e7abdd7e5f9
Reviewed-on: https://go-review.googlesource.com/18441Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes build.

Change-Id: I5235deed7b93157854acb79c15e2e99cc28d300a
Reviewed-on: https://go-review.googlesource.com/18456Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I728d4c709c4122fe4b96e1350be73696ac6fb1f7
Reviewed-on: https://go-review.googlesource.com/18422Reviewed-by: Ian Lance Taylor <iant@golang.org>

There are fewer special cases this way: the import map applies
to all import paths, not just the ones not spelled "unsafe".

This is also consistent with what the code in cmd/go and go/build expects.
They make no exception for "unsafe".

For #13703.

Change-Id: I622295261ca35a6c1e83e8508d363bddbddb6c0a
Reviewed-on: https://go-review.googlesource.com/18438Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Third time's a charm.

Thanks to Ralph Corderoy for noticing the DEL omission.

Update #11207

Change-Id: I174fd01eaecceae1eb220f2c9136e12d40fbe943
Reviewed-on: https://go-review.googlesource.com/18375Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Looking for vendor directories is a better default.

Fixes #13772

Change-Id: Iabbaea71ccc67b72f14f1f412dc8ab70cb41996d
Reviewed-on: https://go-review.googlesource.com/18450Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

We're only getting away with it today by luck.

Change-Id: I24d1cceee4d20c5181ca64fceda152e875f6ad81
Reviewed-on: https://go-review.googlesource.com/18440
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Also nosplit where needed.

Change-Id: I1e3f6f8f76df9ee7e87ed1b8560cef145928314c
Reviewed-on: https://go-review.googlesource.com/18395Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This reverts commit bb8c2e19.

Change-Id: I9bc089e9f2296805ef055b98e8c86ba73af30226
Reviewed-on: https://go-review.googlesource.com/18439Reviewed-by: Russ Cox <rsc@golang.org>

The cgoTestSO test currently fails when run on FreeBSD amd64 with
GOHOSTARCH=386. This is due to it failing to find the shared object.

On FreeBSD 64-bit architectures, the linker for 32-bit objects
looks for a separate environment variable. Export both LD_LIBRARY_PATH
and LD_32_LIBRARY_PATH on FreeBSD when GOHOSTARCH=386.

Update issue #13873.

Change-Id: I1fb20dd04eb2007061768b2e4530886521813d42
Reviewed-on: https://go-review.googlesource.com/18420Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Reading 32,767 is too many on some versions of Windows.
The exact upper bound is unclear.

For #13697, but may not fix the problem on all systems.

Change-Id: I197021ed60cbcd33c91ca6ceed456ec3d5a6c9d6
Reviewed-on: https://go-review.googlesource.com/18433Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In the past, `a.*?c|a.*?b` was factored to `a.*?[bc]`. Thus, given
"abc" as its input string, the automaton would consume "ab" and
then stop (when unanchored) whereas it should consume all of "abc"
as per leftmost semantics.

Fixes #13812.

Change-Id: I67ac0a353d7793b3d0c9c4aaf22d157621dfe784
Reviewed-on: https://go-review.googlesource.com/18357Reviewed-by: Russ Cox <rsc@golang.org>

Ads documentation for both formats of messages accepted by
ReadResponse(). Validity of message should not be altered by
the validation process. On message with unexpected code,
a properly formatted message was not fully read.

Fixes #10230

Change-Id: Ic0b473059a68ab624ce0525e359d0f5d0b8d2117
Reviewed-on: https://go-review.googlesource.com/18172Reviewed-by: Russ Cox <rsc@golang.org>

Previously it depended on whether we were using the Go resolver or the Cgo resolver.

Fixes #12421.

Change-Id: Ib162e336f30f736d7244e29d96651c3be11fc3cd
Reviewed-on: https://go-review.googlesource.com/18383Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CL 4310 introduced these functions, but their
implementation does not match with their published
documentation. Correct the implementation.

Change-Id: I285e41f9c7c5fc4e550ff59b0adb8b2bcbf6737a
Reviewed-on: https://go-review.googlesource.com/17997Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13867.

Change-Id: I6c0a6c64369681840df60f63036c2eece27de8b8
Reviewed-on: https://go-review.googlesource.com/18394Reviewed-by: Russ Cox <rsc@golang.org>

For #13677, but there is more to do.

Change-Id: Id1af999dc972d07cdfc771e5855a1a7dca47ca96
Reviewed-on: https://go-review.googlesource.com/18046Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Today, signal.Ignore(syscall.SIGTRAP) does nothing
while signal.Notify(make(chan os.Signal), syscall.SIGTRAP)
correctly discards user-generated SIGTRAPs.
The same applies to any signal that we throw on.

Make signal.Ignore work for these signals.

Fixes #12906.

Change-Id: Iba244813051e0ce23fa32fbad3e3fa596a941094
Reviewed-on: https://go-review.googlesource.com/18348Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

OS X unconditionally sets si_code = TRAP_BRKPT when sending SIGTRAP,
even if it was generated by kill -TRAP and not a breakpoint.
Correct the si_code by looking to see if the PC is after a breakpoint.

For #12906.

Change-Id: I998c2499f7f12b338e607282a325b045f1f4f690
Reviewed-on: https://go-review.googlesource.com/18347Reviewed-by: Ian Lance Taylor <iant@golang.org>

This reverts commit c5bafc82.

Change-Id: Ie7030c978c6263b9e996d5aa0e490086796df26d
Reviewed-on: https://go-review.googlesource.com/18431Reviewed-by: Russ Cox <rsc@golang.org>

Before, NumGoroutine counted system goroutines and Stack (usually) didn't show them,
which was inconsistent and confusing.

To resolve which way they should be consistent, it seems like

	package main
	import "runtime"
	func main() { println(runtime.NumGoroutine()) }

should print 1 regardless of internal runtime details. Make it so.

Fixes #11706.

Change-Id: I6bfe26a901de517728192cfb26a5568c4ef4fe47
Reviewed-on: https://go-review.googlesource.com/18343Reviewed-by: Austin Clements <austin@google.com>

Fixes #13384.

Change-Id: Id9e827acddc8de139f93c5de0c6486bc4334c7d4
Reviewed-on: https://go-review.googlesource.com/18330Reviewed-by: Ian Lance Taylor <iant@golang.org>

Based on comments from Thomas Bushnell.

Update #9896.

Change-Id: I603b1382d17dff00b5d18f17f8b5d011503e9e4c
Reviewed-on: https://go-review.googlesource.com/18365Reviewed-by: Russ Cox <rsc@golang.org>

Rename should remove newname if the file already exists
and is not a directory.

Fixes #13844.

Change-Id: I85a5cc28e8d161637a8bc1de33f4a637d9154cd1
Reviewed-on: https://go-review.googlesource.com/18291Reviewed-by: Russ Cox <rsc@golang.org>