TestUnshareMountNameSpace fails on arm64 due to permission problems.

Skip that test for now when permission problems are encountered, so we
don't regress elsewhere in the meantime.

Updates #19698

Change-Id: I9058928afa474b813652c9489f343b8957160a6c
Reviewed-on: https://go-review.googlesource.com/39052
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Currently runtime.GC() triggers a STW GC. For common uses in tests and
benchmarks, it doesn't matter whether it's STW or concurrent, but for
uses in servers for things like collecting heap profiles and
controlling memory footprint, this pause can be a bit problem for
latency.

This changes runtime.GC() to trigger a concurrent GC. In order to
remain as close as possible to its current meaning, we define it to
always perform a full mark/sweep GC cycle before returning (even if
that means it has to finish up a cycle we're in the middle of first)
and to publish the heap profile as of the triggered mark termination.
While it must perform a full cycle, simultaneous runtime.GC() calls
can be consolidated into a single full cycle.

Fixes #18216.

Change-Id: I9088cc5deef4ab6bcf0245ed1982a852a01c44b5
Reviewed-on: https://go-review.googlesource.com/37520
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

sweepone returns ^uintptr(0) when there are no more spans to *start*
sweeping, but there may be spans being swept concurrently at the time
and there's currently no efficient way to tell when the sweeper is
done sweeping all the spans.

We'll need this for concurrent runtime.GC(), so add a count of the
number of active sweepone calls to make it possible to block until
sweeping is truly done.

This is also useful for more accurately printing the gcpacertrace,
since that should be printed after all of the sweeping stats are in
(currently we can print it slightly too early).

For #18216.

Change-Id: I06e6240c9e7b40aca6fd7b788bb6962107c10a0f
Reviewed-on: https://go-review.googlesource.com/37716
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Forced GCs don't provide good information about how to adjust the GC
trigger. Currently we avoid adjusting the trigger on forced GC because
forced GC is also STW and we don't adjust the trigger on STW GC.
However, this will become a problem when forced GC is concurrent.

Fix this by skipping trigger adjustment if the GC was user-forced.

For #18216.

Change-Id: I03dfdad12ecd3cfeca4573140a0768abb29aac5e
Reviewed-on: https://go-review.googlesource.com/38951
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently gcMode != gcBackgroundMode implies this was a user-forced GC
cycle. This is no longer going to be true when we make runtime.GC()
trigger a concurrent GC, so replace this with an explicit
work.userForced bit.

For #18216.

Change-Id: If7d71bbca78b5f0b35641b070f9d457f5c9a52bd
Reviewed-on: https://go-review.googlesource.com/37519
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently freeOSMemory calls gcStart directly, but we really just want
it to behave like runtime.GC() and then perform a scavenge, so make it
call runtime.GC() rather than gcStart.

For #18216.

Change-Id: I548ec007afc788e87d383532a443a10d92105937
Reviewed-on: https://go-review.googlesource.com/37518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Now that the gcMode is no longer involved in the GC trigger condition,
we can simplify the triggering of forced GCs. By making the trigger
condition for forced GCs true even if gcphase is not _GCoff, we don't
need any special case path in gcStart to ensure that forced GCs don't
get consolidated.

Change-Id: I6067a13d76e40ff2eef8fade6fc14adb0cb58ee5
Reviewed-on: https://go-review.googlesource.com/37517
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently the GC triggering condition is an awkward combination of the
gcMode (whether or not it's gcBackgroundMode) and a boolean
"forceTrigger" flag.

Replace this with a new gcTrigger type that represents the range of
transition predicates we need. This has several advantages:

1. We can remove the awkward logic that affects the trigger behavior
   based on the gcMode. Now gcMode purely controls whether to run a
   STW GC or not and the gcTrigger controls whether this is a forced
   GC that cannot be consolidated with other GC cycles.

2. We can lift the time-based triggering logic in sysmon to just
   another type of GC trigger and move the logic to the trigger test.

3. This sets us up to have a cycle count-based trigger, which we'll
   use to make runtime.GC trigger concurrent GC with the desired
   consolidation properties.

For #18216.

Change-Id: If9cd49349579a548800f5022ae47b8128004bbfc
Reviewed-on: https://go-review.googlesource.com/37516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently sysmon triggers periodic GC if GC is not currently running
and it's been long enough since the last GC. This misses some
important conditions; for example, whether GC is enabled at all by
GOGC. As a result, if GOGC is off, once we pass the timeout for
periodic GC, sysmon will attempt to trigger a GC every 10ms. This GC
will be a no-op because gcStart will check all of the appropriate
conditions and do nothing, but it still goes through the motions of
waking the forcegc goroutine and printing a gctrace line.

Fix this by making sysmon call gcShouldStart to check *all* of the
appropriate transition conditions before attempting to trigger a
periodic GC.

Fixes #19247.

Change-Id: Icee5521ce175e8419f934723849853d53773af31
Reviewed-on: https://go-review.googlesource.com/37515
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently the heap profile is flushed by *either* gcSweep in STW mode
or by gcMarkTermination in concurrent mode. Simplify this by making
gcMarkTermination always flush the heap profile and by making gcSweep
do one extra flush (instead of two) in STW mode.

Change-Id: I62147afb2a128e1f3d92ef4bb8144c8a345f53c4
Reviewed-on: https://go-review.googlesource.com/37715
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently we snapshot the heap profile just *after* mark termination
starts the world because it's a relatively expensive operation.
However, this means any alloc or free events that happen between
starting the world and snapshotting the heap profile can be accounted
to the wrong cycle. In the worst case, a free can be accounted to the
cycle before the alloc; if the heap is small, this can result
temporarily in a negative "in use" count in the profile.

Fix this without making STW more expensive by using a global heap
profile cycle counter. This lets us split up the operation into a two
parts: 1) a super-cheap snapshot operation that simply increments the
global cycle counter during STW, and 2) a more expensive cleanup
operation we can do after starting the world that frees up a slot in
all buckets for use by the next heap profile cycle.

Fixes #19311.

Change-Id: I6bdafabf111c48b3d26fe2d91267f7bef0bd4270
Reviewed-on: https://go-review.googlesource.com/37714
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently memRecord has the same set of four fields repeated three
times. Pull these into a type and use this type three times. This
cleans up and simplifies the code a bit and will make it easier to
switch to a globally tracked heap profile cycle for #19311.

Change-Id: I414d15673feaa406a8366b48784437c642997cf2
Reviewed-on: https://go-review.googlesource.com/37713
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

The symExport flag tells whether a symbol is in the export list
already or not (and it's also used to avoid being added to that
list). Exporting is based on that export list - no need to check
again.

Change-Id: I6056f97aa5c24a19376957da29199135c8da35f9
Reviewed-on: https://go-review.googlesource.com/39033Reviewed-by: Dave Cheney <dave@cheney.net>

Every time I modify heap profiling, I find myself redrawing this
diagram, so add it to the comments. This shows how allocations and
frees are accounted, how we arrive at consistent profile snapshots,
and when those snapshots are published to the user.

Change-Id: I106aba1200af3c773b46e24e5f50205e808e2c69
Reviewed-on: https://go-review.googlesource.com/37514
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Now that we have a nice predicate system, improve the tests performed
by TestMemStats. We add some more non-zero checks (now that we force a
GC, things like NumGC must be non-zero), checks for trivial boolean
fields, and a few more range checks.

Change-Id: I6da46d33fa0ce5738407ee57d587825479413171
Reviewed-on: https://go-review.googlesource.com/37513
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently most TestMemStats failures dump the whole MemStats object if
anything is amiss without telling you what is amiss, or even which
field is wrong. This makes it hard to figure out what the actual
problem is.

Replace this with a reflection walk over MemStats and a map of
predicates to check. If one fails, we can construct a detailed and
descriptive error message. The predicates are a direct translation of
the current tests.

Change-Id: I5a7cafb8e6a1eeab653d2e18bb74e2245eaa5444
Reviewed-on: https://go-review.googlesource.com/37512
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: I4de5173fa50fbf90802d1d2428824702f2118dde
Reviewed-on: https://go-review.googlesource.com/39030
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Hwindowsgui has the same meaning as Hwindows - build PE
executable. So use Hwindows everywhere.

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

cmd/link -H flag is stored in variable of type
cmd/internal/obj.HeadType. The HeadType type from cmd/internal/obj
accepts Hwindows and Hwindowsgui values, but these values have
same meaning - build PE executable, except for 2 places in
cmd/link/internal/ld package.

This CL introduces code to store cmd/link "windowsgui" -H flag
in cmd/link/internal/ld, so cmd/internal/obj.Hwindowsgui can be
removed in the next CL.

This CL also includes 2 changes to code where distinction
between Hwindows and Hwindowsgui is important.

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

While we're here, fix a Skip/Skipf error I noticed.

Fixes #19796.

Change-Id: I59b1f5b5ea727fc314acfee8445b3de0b5af1e46
Reviewed-on: https://go-review.googlesource.com/38992
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Remove one of the many lookup variants.

Change-Id: I4095aa030da4227540badd6724bbf50b728fbe93
Reviewed-on: https://go-review.googlesource.com/38990Reviewed-by: Dave Cheney <dave@cheney.net>

Change-Id: I08c264f5f3744d835e407534c492ef8c43e1a700
Reviewed-on: https://go-review.googlesource.com/38991
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Instead, add a scratchFpMem field to ssafn,
so that it may be passed on to genssa.

Updates #15756

Change-Id: Icdeae290d3098d14d31659fa07a9863964bb76ed
Reviewed-on: https://go-review.googlesource.com/38728Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

During the review of CL 38801 it was noted that it would be nice
to have a bit more clarity on how-and-why SB addressing is handled
strangely on s390x. This additional comment should hopefully help.

In general SB is handled differently because not all instructions
have variants that use relative addressing.

Change-Id: I3379012ae3f167478c191c435939c3b876c645ed
Reviewed-on: https://go-review.googlesource.com/38952Reviewed-by: Keith Randall <khr@golang.org>

The preceding passes have caught any errors
that could occur during SSA construction.

Updates #19250

Change-Id: I736edb2017da3f111fb9f74be12d437b5a24d2b4
Reviewed-on: https://go-review.googlesource.com/38971
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This is a better home for it.

Change-Id: I7ce96c16378d841613edaa53c07347b0ac99ea6e
Reviewed-on: https://go-review.googlesource.com/38970
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

TestDWARF has been added in CL 38855. This test is
failing on Plan 9 because executables don't have
a DWARF symbol table.

Fixes #19793.

Change-Id: I7fc547a7c877b58cc4ff6b4eb5b14852e8b4668b
Reviewed-on: https://go-review.googlesource.com/38931
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Even very large Types are not very big.
The haspointer cache looks like premature optimization.
Removing them has no detectable compiler performance impact,
and it removes mutable shared state used by the backend.

Updates #15756

Change-Id: I2d2cf03f470f5eef5bcd50ff693ef6a01d481700
Reviewed-on: https://go-review.googlesource.com/38912
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Flush file content to disk before diffing files,
may cause unpredictable results on Windows.

Convert from \r\n to \n when comparing diff result.

Change-Id: Ibcd6154a2382dba1338ee5674333611aea16bb65
Reviewed-on: https://go-review.googlesource.com/36750Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>

REV/REV16/REVSH were introduced in ARMv6, they offered more efficient
byte reverse operatons.

MMUL/MMULA/MMULS were introduced in ARMv6, they simplified
a serial of mul->shift->add/sub operations into a single instruction.

RBIT was introduced in ARMv7, it inversed a 32-bit word's bit order.

MULS was introduced in ARMv7, it corresponded to MULA.

MULBB/MULABB were introduced in ARMv5TE, they performed 16-bit
multiplication (and accumulation).

Change-Id: I6365b17b3c4eaf382a657c210bb0094b423b11b8
Reviewed-on: https://go-review.googlesource.com/35565
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

100% code movement.

Change-Id: Idb51c61b7363229258a3b48045e901bea68c7a85
Reviewed-on: https://go-review.googlesource.com/38911
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I162e86e5f92c8b827a74ee860d16abadf83bc43e
Reviewed-on: https://go-review.googlesource.com/38910
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CL 38147 eliminated package gc globals in formatting routines.
However, tconv still used the Type field Trecur
to avoid infinite recursion when formatting recursive
interfaces types such as (test/fixedbugs398.go):

type i1 interface {
	F() interface {
		i1
	}
}

type i2 interface {
	F() interface {
		i2
	}
}

This CL changes the recursion prevention to use a parameter,
and threads it through the formatting routines.
Because this fundamentally limits the embedding depth
of all types, it sets the depth limit to be much higher.
In practice, it is unlikely to impact any code at all,
one way or the other.

The remaining uses of Type.Trecur are boolean in nature.
A future CL will change Type.Trecur to be a boolean flag.

The removal of a couple of mode.Sprintf calls
makes this a very minor net performance improvement:

name       old alloc/op    new alloc/op    delta
Template      40.0MB ± 0%     40.0MB ± 0%  -0.13%  (p=0.032 n=5+5)
Unicode       30.0MB ± 0%     29.9MB ± 0%    ~     (p=0.310 n=5+5)
GoTypes        114MB ± 0%      113MB ± 0%  -0.25%  (p=0.008 n=5+5)
SSA            856MB ± 0%      855MB ± 0%  -0.04%  (p=0.008 n=5+5)
Flate         25.5MB ± 0%     25.4MB ± 0%  -0.27%  (p=0.008 n=5+5)
GoParser      31.9MB ± 0%     31.9MB ± 0%    ~     (p=0.222 n=5+5)
Reflect       79.0MB ± 0%     78.6MB ± 0%  -0.45%  (p=0.008 n=5+5)
Tar           26.8MB ± 0%     26.7MB ± 0%  -0.25%  (p=0.032 n=5+5)
XML           42.4MB ± 0%     42.4MB ± 0%    ~     (p=0.151 n=5+5)

name       old allocs/op   new allocs/op   delta
Template        395k ± 0%       391k ± 0%  -1.00%  (p=0.008 n=5+5)
Unicode         321k ± 1%       319k ± 0%  -0.56%  (p=0.008 n=5+5)
GoTypes        1.16M ± 0%      1.14M ± 0%  -1.61%  (p=0.008 n=5+5)
SSA            7.63M ± 0%      7.60M ± 0%  -0.30%  (p=0.008 n=5+5)
Flate           239k ± 0%       234k ± 0%  -1.94%  (p=0.008 n=5+5)
GoParser        320k ± 0%       317k ± 1%  -0.86%  (p=0.008 n=5+5)
Reflect        1.00M ± 0%      0.98M ± 0%  -2.17%  (p=0.016 n=4+5)
Tar             255k ± 1%       251k ± 0%  -1.35%  (p=0.008 n=5+5)
XML             398k ± 0%       395k ± 0%  -0.89%  (p=0.008 n=5+5)

Updates #15756

Change-Id: Id23e647d347aa841f9a69d51f7d2d7d27b259239
Reviewed-on: https://go-review.googlesource.com/38797
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Right now, at least with Xcode 8.3, we invoke dsymutil and dutifully
copy what it produces back into the binary, but it has actually dropped
all the DWARF information that we wanted, because it didn't like
the look of go.o.

Make it like the look of go.o.

DWARF is tested in other ways, but typically indirectly and not for cgo programs.
Add a direct test, and one that exercises cgo.
This detects missing dwarf information in cgo-using binaries on macOS,
at least with Xcode 8.3, and possibly earlier versions as well.

Fixes #19772.

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

Place comments correctly.
Simplify control flow.
Reduce variable scope.

Passes toolstash-check.

Change-Id: Iea47ed3502c15491c2ca6db8149fe0949b8849aa
Reviewed-on: https://go-review.googlesource.com/38914
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Now that we no longer generate dead code,
it is possible to follow block predecessors
into infinite loops with no variable definitions,
causing an infinite loop during phi insertion.

To fix that, check explicitly whether the predecessor
is dead in lookupVarOutgoing, and if so, bail.

The loop in lookupVarOutgoing is very hot code,
so I am wary of adding anything to it.
However, a long, CPU-only benchmarking run shows no
performance impact at all.

Fixes #19783

Change-Id: I8ef8d267e0b20a29b5cb0fecd7084f76c6f98e47
Reviewed-on: https://go-review.googlesource.com/38913Reviewed-by: David Chase <drchase@google.com>

We use an "autogenerated" position in several places.
Rather than recreate it each time, make one early on and reuse it.
This removes the creation of new positions during the backend,
which was not concurrency-safe.

Updates #15756

Change-Id: Ic116b2e60f0e99de1a2ea87fe763831b50b645f8
Reviewed-on: https://go-review.googlesource.com/38915
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Without this, the load fails during kernel exec, which results in the
mysterious and completely uninformative "Killed: 9" error.

It appears that the stars (or at least the inputs) were properly aligned
with earlier versions of Xcode so that this happened accidentally.
Make it happen on purpose.

Gregory Man bisected the breakage to this change in LLVM,
which fits the theory nicely:
https://github.com/llvm-mirror/llvm/commit/9a41e59c

Fixes #19734.

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

Might as well provide a way around the mach-o munging
that doesn't require stripping all symbols.
After all, -w does mean no DWARF.

For #11887, #19734, and anyone else that needs to disable
this code path without losing the symbol table.

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

This keeps the host linker from printing
ld: warning: option -s is obsolete and being ignored

Fixes #19775.

Change-Id: I18dd4e4b3f59cbf35dad770fd65e6baea5a7347f
Reviewed-on: https://go-review.googlesource.com/38851
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>