- 27 Apr, 2016 6 commits
-
-
Dave Cheney authored
Updates #15462 Semi automatic change with gofmt -r and hand fixups for callers outside internal/gc. All the uses of gc.Oconv outside cmd/compile/internal/gc were for the Oconv(op, 0) form, which is already handled the Op.String method. Replace the use of gc.Oconv(op, 0) with op itself, which will call Op.String via the %v or %s verb. Unexport Oconv. Change-Id: I84da2a2e4381b35f52efce427b2d6a3bccdf2526 Reviewed-on: https://go-review.googlesource.com/22496 Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Josh Bleecher Snyder authored
Change-Id: Ief4707747338912216a8509b1adbf655c8ffac56 Reviewed-on: https://go-review.googlesource.com/22495 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Previously the Transport would cache idle connections from the Transport for later reuse, but if a peer server disconnected (e.g. idle timeout), we would not proactively remove the *persistConn from the Transport's idle list, leading to a waste of memory (potentially forever). Instead, when the persistConn's readLoop terminates, remote it from the idle list, if present. This also adds the beginning of accounting for the total number of idle connections, which will be needed for Transport.MaxIdleConns later. Updates #15461 Change-Id: Iab091f180f8dd1ee0d78f34b9705d68743b5557b Reviewed-on: https://go-review.googlesource.com/22492Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Brad Fitzpatrick authored
Fixes #15449 Change-Id: I8d84d076a05c56694b48f7b84f572b1a6524f522 Reviewed-on: https://go-review.googlesource.com/22493Reviewed-by:
-
Russ Cox authored
It comes up every few months that we can't understand why the go command is rebuilding some package. Add diagnostics so that the go command can explain itself if asked. For #2775, #3506, #12074. Change-Id: I1c73b492589b49886bf31a8f9d05514adbd6ed70 Reviewed-on: https://go-review.googlesource.com/22432Reviewed-by:
Rob Pike <r@golang.org>
-
Michael Munday authored
Renames block to blockGeneric so that it can be called when the assembly feature check fails. This means making block a var on platforms without an assembly implementation (similar to the sha1 package). Also adds a test to check that the fallback path works correctly when the feature check fails. name old speed new speed delta Hash8Bytes 6.42MB/s ± 1% 27.14MB/s ± 0% +323.01% (p=0.000 n=10+10) Hash1K 53.9MB/s ± 0% 511.1MB/s ± 0% +847.57% (p=0.000 n=10+9) Hash8K 57.1MB/s ± 1% 609.7MB/s ± 0% +967.04% (p=0.000 n=10+10) Change-Id: If962b2a5c9160b3a0b76ccee53b2fd809468ed3d Reviewed-on: https://go-review.googlesource.com/22460 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bill O'Farrell <billotosyr@gmail.com> Reviewed-by:
-
- 26 Apr, 2016 23 commits
-
-
Austin Clements authored
Currently the stack re-scan during mark termination is O(# stacks) because we enqueue a root marking job for every goroutine. It takes ~34ns to process this root marking job for a valid (clean) stack, so at around 300k goroutines we exceed the 10ms pause goal. A non-trivial portion of this time is spent simply taking the cache miss to check the gcscanvalid flag, so simply optimizing the path that handles clean stacks can only improve this so much. Fix this by keeping an explicit list of goroutines with dirty stacks that need to be rescanned. When a goroutine first transitions to running after a stack scan and marks its stack dirty, it adds itself to this list. We enqueue root marking jobs only for the goroutines in this list, so this improves stack re-scanning asymptotically by completely eliminating time spent on clean goroutines. This reduces mark termination time for 500k idle goroutines from 15ms to 238µs. Overall performance effect is negligible. name \ 95%ile-time/markTerm old new delta IdleGs/gs:500000/gomaxprocs:12 15000µs ± 0% 238µs ± 5% -98.41% (p=0.000 n=10+10) name old time/op new time/op delta XBenchGarbage-12 2.30ms ± 3% 2.29ms ± 1% -0.43% (p=0.049 n=17+18) name old time/op new time/op delta BinaryTree17-12 2.57s ± 3% 2.59s ± 2% ~ (p=0.141 n=19+20) Fannkuch11-12 2.09s ± 0% 2.10s ± 1% +0.53% (p=0.000 n=19+19) FmtFprintfEmpty-12 45.3ns ± 3% 45.2ns ± 2% ~ (p=0.845 n=20+20) FmtFprintfString-12 129ns ± 0% 127ns ± 0% -1.55% (p=0.000 n=16+16) FmtFprintfInt-12 123ns ± 0% 119ns ± 1% -3.24% (p=0.000 n=19+19) FmtFprintfIntInt-12 195ns ± 1% 189ns ± 1% -3.11% (p=0.000 n=17+17) FmtFprintfPrefixedInt-12 193ns ± 1% 187ns ± 1% -3.06% (p=0.000 n=19+19) FmtFprintfFloat-12 254ns ± 0% 255ns ± 1% +0.35% (p=0.001 n=14+17) FmtManyArgs-12 781ns ± 0% 770ns ± 0% -1.48% (p=0.000 n=16+19) GobDecode-12 7.00ms ± 1% 6.98ms ± 1% ~ (p=0.563 n=19+19) GobEncode-12 5.91ms ± 1% 5.92ms ± 0% ~ (p=0.118 n=19+18) Gzip-12 219ms ± 1% 215ms ± 1% -1.81% (p=0.000 n=18+18) Gunzip-12 37.2ms ± 0% 37.4ms ± 0% +0.45% (p=0.000 n=17+19) HTTPClientServer-12 76.9µs ± 3% 77.5µs ± 2% +0.81% (p=0.030 n=20+19) JSONEncode-12 15.0ms ± 0% 14.8ms ± 1% -0.88% (p=0.001 n=15+19) JSONDecode-12 50.6ms ± 0% 53.2ms ± 2% +5.07% (p=0.000 n=17+19) Mandelbrot200-12 4.05ms ± 0% 4.05ms ± 1% ~ (p=0.581 n=16+17) GoParse-12 3.34ms ± 1% 3.30ms ± 1% -1.21% (p=0.000 n=15+20) RegexpMatchEasy0_32-12 69.6ns ± 1% 69.8ns ± 2% ~ (p=0.566 n=19+19) RegexpMatchEasy0_1K-12 238ns ± 1% 236ns ± 0% -0.91% (p=0.000 n=17+13) RegexpMatchEasy1_32-12 69.8ns ± 1% 70.0ns ± 1% +0.23% (p=0.026 n=17+16) RegexpMatchEasy1_1K-12 371ns ± 1% 363ns ± 1% -2.07% (p=0.000 n=19+19) RegexpMatchMedium_32-12 107ns ± 2% 106ns ± 1% -0.51% (p=0.031 n=18+20) RegexpMatchMedium_1K-12 33.0µs ± 0% 32.9µs ± 0% -0.30% (p=0.004 n=16+16) RegexpMatchHard_32-12 1.70µs ± 0% 1.70µs ± 0% +0.45% (p=0.000 n=16+17) RegexpMatchHard_1K-12 51.1µs ± 2% 51.4µs ± 1% +0.53% (p=0.000 n=17+19) Revcomp-12 378ms ± 1% 385ms ± 1% +1.92% (p=0.000 n=19+18) Template-12 64.3ms ± 2% 65.0ms ± 2% +1.09% (p=0.001 n=19+19) TimeParse-12 315ns ± 1% 317ns ± 2% ~ (p=0.108 n=18+20) TimeFormat-12 360ns ± 1% 337ns ± 0% -6.30% (p=0.000 n=18+13) [Geo mean] 51.8µs 51.6µs -0.48% Change-Id: Icf8994671476840e3998236e15407a505d4c760c Reviewed-on: https://go-review.googlesource.com/20700Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently we clear gcscanvalid in both casgstatus and casfrom_Gscanstatus if the new status is _Grunning. This is very important to do in casgstatus. However, this is potentially wrong in casfrom_Gscanstatus because in this case the caller doesn't own gp and hence the write is racy. Unlike the other _Gscan statuses, during _Gscanrunning, the G is still running. This does not indicate that it's transitioning into a running state. The scan simply hasn't happened yet, so it's neither valid nor invalid. Conveniently, this also means clearing gcscanvalid is unnecessary in this case because the G was already in _Grunning, so we can simply remove this code. What will happen instead is that the G will be preempted to scan itself, that scan will set gcscanvalid to true, and then the G will return to _Grunning via casgstatus, clearing gcscanvalid. This fix will become necessary shortly when we start keeping track of the set of G's with dirty stacks, since it will no longer be idempotent to simply set gcscanvalid to false. Change-Id: I688c82e6fbf00d5dbbbff49efa66acb99ee86785 Reviewed-on: https://go-review.googlesource.com/20669Reviewed-by:
-
Austin Clements authored
Change-Id: Id4ad7ebf88a21eba2bc5714b96570ed5cfaed757 Reviewed-on: https://go-review.googlesource.com/22210Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
This adds a best-effort pass to remove stack barriers immediately after the end of mark termination. This isn't necessary for the Go runtime, but should help external tools that perform stack walks but aren't aware of Go's stack barriers such as GDB, perf, and VTune. (Though clearly they'll still have trouble unwinding stacks during mark.) Change-Id: I66600fae1f03ee36b5459d2b00dcc376269af18e Reviewed-on: https://go-review.googlesource.com/20668Reviewed-by:
-
Austin Clements authored
Currently we remove stack barriers during STW mark termination, which has a non-trivial per-goroutine cost and means that we have to touch even clean stacks during mark termination. However, there's no problem with leaving them in during the sweep phase. They just have to be out by the time we install new stack barriers immediately prior to scanning the stack such as during the mark phase of the next GC cycle or during mark termination in a STW GC. Hence, move the gcRemoveStackBarriers from STW mark termination to just before we install new stack barriers during concurrent mark. This removes the cost from STW. Furthermore, this combined with concurrent stack shrinking means that the mark termination scan of a clean stack is a complete no-op, which will make it possible to skip clean stacks entirely during mark termination. This has the downside that it will mess up anything outside of Go that tries to walk Go stacks all the time instead of just some of the time. This includes tools like GDB, perf, and VTune. We'll improve the situation shortly. Change-Id: Ia40baad8f8c16aeefac05425e00b0cf478137097 Reviewed-on: https://go-review.googlesource.com/20667Reviewed-by:
-
Austin Clements authored
Currently we enqueue span root mark jobs during both concurrent mark and mark termination, but we make the job a no-op during mark termination. This is silly. Instead of queueing them up just to not do them, don't queue them up in the first place. Change-Id: Ie1d36de884abfb17dd0db6f0449a2b7c997affab Reviewed-on: https://go-review.googlesource.com/20666Reviewed-by:
-
Austin Clements authored
Currently we free cached stacks of dead Gs during STW stack root marking. We do this during STW because there's no way to take ownership of a particular dead G, so attempting to free a dead G's stack during concurrent stack root marking could race with reusing that G. However, we can do this concurrently if we take a completely different approach. One way to prevent reuse of a dead G is to remove it from the free G list. Hence, this adds a new fixed root marking task that simply removes all Gs from the list of dead Gs with cached stacks, frees their stacks, and then adds them to the list of dead Gs without cached stacks. This is also a necessary step toward rescanning only dirty stacks, since it eliminates another task from STW stack marking. Change-Id: Iefbad03078b284a2e7bf30fba397da4ca87fe095 Reviewed-on: https://go-review.googlesource.com/20665Reviewed-by:
-
Austin Clements authored
Currently all free Gs are added to one list. Split this into two lists: one for free Gs with cached stacks and one for Gs without cached stacks. This lets us preferentially allocate Gs that already have a stack, but more importantly, it sets us up to free cached G stacks concurrently. Change-Id: Idbe486f708997e1c9d166662995283f02d1eeb3c Reviewed-on: https://go-review.googlesource.com/20664Reviewed-by:
-
Keith Randall authored
Let's define the line number of a multiline rule as the line number on which the -> appears. This helps make the rule cover analysis look a bit nicer. Change-Id: I4ac4c09f2240285976590ecfd416bc4c05e78946 Reviewed-on: https://go-review.googlesource.com/22473Reviewed-by:
-
Matthew Dempsky authored
Instead of eagerly creating strings like "literal 2.01" for every lexed number in case we need to mention it in an error message, defer this work to (*parser).syntax_error. name old allocs/op new allocs/op delta Template 482k ± 0% 482k ± 0% -0.12% (p=0.000 n=9+10) GoTypes 1.35M ± 0% 1.35M ± 0% -0.04% (p=0.015 n=10+10) Compiler 5.45M ± 0% 5.44M ± 0% -0.12% (p=0.000 n=9+8) Change-Id: I333b3c80e583864914412fb38f8c0b7f1d8c8821 Reviewed-on: https://go-review.googlesource.com/22480 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
This simplifies comparison of object files across different builds by ensuring that the strings in the zcgo.go always appear in the same order. Change-Id: I3639ea4fd10e0d645b838d1bbb03cd33deca340e Reviewed-on: https://go-review.googlesource.com/22478Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Egon Elbre authored
This change significantly speeds up case-insensitive regexp matching. benchmark old ns/op new ns/op delta BenchmarkMatchEasy0i_32-8 2690 1473 -45.24% BenchmarkMatchEasy0i_1K-8 80404 42269 -47.43% BenchmarkMatchEasy0i_32K-8 3272187 2076118 -36.55% BenchmarkMatchEasy0i_1M-8 104805990 66503805 -36.55% BenchmarkMatchEasy0i_32M-8 3360192200 2126121600 -36.73% benchmark old MB/s new MB/s speedup BenchmarkMatchEasy0i_32-8 11.90 21.72 1.83x BenchmarkMatchEasy0i_1K-8 12.74 24.23 1.90x BenchmarkMatchEasy0i_32K-8 10.01 15.78 1.58x BenchmarkMatchEasy0i_1M-8 10.00 15.77 1.58x BenchmarkMatchEasy0i_32M-8 9.99 15.78 1.58x Issue #13288 Change-Id: I94af7bb29e75d60b4f6ee760124867ab271b9642 Reviewed-on: https://go-review.googlesource.com/16943Reviewed-by:
-
Alan Donovan authored
This version of the file name honors the -trimprefix flag, which strips off variable parts like $WORK or $PWD. The TestCgoConsistentResults test now passes. Change-Id: If93980b054f9b13582dd314f9d082c26eaac4f41 Reviewed-on: https://go-review.googlesource.com/22444Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
Change-Id: I0f016fa000f949d27847d645b4cdebe68a8abf20 Reviewed-on: https://go-review.googlesource.com/22474 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
-
Michael Hudson-Doyle authored
Fixes #15443 Change-Id: Ia3593104fc1a4255926ae5675c25390604b44b7b Reviewed-on: https://go-review.googlesource.com/22453 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
-
Michael Munday authored
Also adds TestGdbBacktrace to the runtime package. Dwarf modifications written by Bryan Chan (@bryanpkc) who is also at IBM and covered by the same CLA. Fixes #14628 Change-Id: I106a1f704c3745a31f29cdadb0032e3905829850 Reviewed-on: https://go-review.googlesource.com/20193Reviewed-by:
-
Russ Cox authored
The comment says 'DΟ NΟT SUBMIT', and that text being in a file can cause automated errors or warnings when trying to check the Go sources into other source control systems. (We reject that string in CL commit messages, which I've avoided here by changing the O's to Ο's above.) Change-Id: I6cdd57a8612ded5208f05a8bd6b137f44424a030 Reviewed-on: https://go-review.googlesource.com/22434 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Make sure ops have the right number of args, set aux and auxint only if allowed, etc. Normalize error reporting format. Change-Id: Ie545fcc5990c8c7d62d40d9a0a55885f941eb645 Reviewed-on: https://go-review.googlesource.com/22320Reviewed-by:
David Chase <drchase@google.com>
-
Michael Munday authored
Renames block to blockGeneric so that it can be called when the assembly feature check fails. This means making block a var on platforms without an assembly implementation (similar to the sha1 package). Also adds a test to check that the fallback path works correctly when the feature check fails. name old speed new speed delta Hash8Bytes 7.13MB/s ± 2% 19.89MB/s ± 1% +178.82% (p=0.000 n=9+10) Hash1K 121MB/s ± 1% 661MB/s ± 1% +444.54% (p=0.000 n=10+9) Hash8K 137MB/s ± 0% 918MB/s ± 1% +569.29% (p=0.000 n=10+10) Change-Id: Id65dd6e943f14eeffe39a904dc88065fc6a60179 Reviewed-on: https://go-review.googlesource.com/22402Reviewed-by:
-
Matthew Dempsky authored
Fixes #15434. Change-Id: Ia88b740df5418a6d3af1c29a03756f4234f388b0 Reviewed-on: https://go-review.googlesource.com/22428Reviewed-by:
-
David Crawshaw authored
The linker was incorrectly decoding type name lengths, causing typelinks to be sorted out of order and in cases where the name was the exact right length, linker panics. Added a test to the reflect package that causes TestTypelinksSorted to fail before this CL. It's not the exact failure seen in #15448 but it has the same cause: decodetype_name calculating the wrong length. The equivalent decoders in reflect/type.go and runtime/type.go have the parenthesis in the right place. Fixes #15448 Change-Id: I33257633d812b7d2091393cb9d6cc8a73e0138c8 Reviewed-on: https://go-review.googlesource.com/22403Reviewed-by:
Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Chase authored
Here, "fix" means "replace". The new dominator computation is the "simple" algorithm from Lengauer and Tarjan's TOPLAS paper, with minimal changes. Also included is a test that tweaks the fixed error. Change-Id: I0abdf53d5d64df1e67e4e62f55e88957045cd63b Reviewed-on: https://go-review.googlesource.com/22401 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Ilya Tocar authored
Use PCMPESTRI instruction if available. Index-4 21.1ns ± 0% 21.1ns ± 0% ~ (all samples are equal) IndexHard1-4 395µs ± 0% 105µs ± 0% -73.53% (p=0.000 n=19+20) IndexHard2-4 300µs ± 0% 147µs ± 0% -51.11% (p=0.000 n=19+20) IndexHard3-4 665µs ± 0% 665µs ± 0% ~ (p=0.942 n=16+19) Change-Id: I4f66794164740a2b939eb1c78934e2390b489064 Reviewed-on: https://go-review.googlesource.com/22337 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 25 Apr, 2016 11 commits
-
-
Robert Griesemer authored
This is not necessary for reproduceability but it removes differences due to imported package order between compiles using textual vs binary export format. The packages list tends to be very short, so it's ok doing it always for now. Guarded with a documented (const) flag so it's trivial to disable and remove eventually. Also, use the same flag now to enforce parameter numbering. Change-Id: Ie05d2490df770239696ecbecc07532ed62ccd5c0 Reviewed-on: https://go-review.googlesource.com/22445 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
-
Keith Randall authored
The code sequence for large-offset floating-point stores includes adding the base pointer to r11. Make sure we can interpret that instruction correctly. Fixes build. Fixes #15440 Change-Id: I7fe5a4a57e08682967052bf77c54e0ec47fcb53e Reviewed-on: https://go-review.googlesource.com/22440Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Robert Griesemer authored
The numbering is only required for parameters of functions/methods with exported inlineable bodies. For now, always export parameter names with internal numbering to minimize the diffs between assembly code dumps of code compiled with the textual vs the binary format. To be disabled again once the new export format is default. Change-Id: I6d14c564e734cc5596c7e995d8851e06d5a35013 Reviewed-on: https://go-review.googlesource.com/22441Reviewed-by:
-
Matthew Dempsky authored
Fixes #15439. Change-Id: I5a32384c46e20f8db6968e5a9e854c45ab262fe4 Reviewed-on: https://go-review.googlesource.com/22429Reviewed-by:
-
Keith Randall authored
Zero the entire buffer so we don't need to lower its capacity upon return. This lets callers do some appending without allocation. Zeroing is cheap, the byte buffer requires only 4 extra instructions. Fixes #14235 Change-Id: I970d7badcef047dafac75ac17130030181f18fe2 Reviewed-on: https://go-review.googlesource.com/22424 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alexandru Moșoi authored
Introduce OrB, EqB, NeqB, AndB to handle bool operations. Change-Id: I53e4d5125a8090d5eeb4576db619103f19fff58d Reviewed-on: https://go-review.googlesource.com/22412Reviewed-by:
-
Robert Griesemer authored
Note that the spec already makes that point with a comment in the very first example for struct field tags. This change is simply stating this explicitly in the actual spec prose. - gccgo and go/types already follow this rule - the current reflect package API doesn't distinguish between absent tags and empty tags (i.e., there is no discoverable difference) Fixes #15412. Change-Id: I92f9c283064137b4c8651630cee0343720717a02 Reviewed-on: https://go-review.googlesource.com/22391Reviewed-by:
-
Josh Bleecher Snyder authored
The underlying issues have been fixed. All the individual fixes have their own tests, but it's still useful to have a plain source test. Fixes #15084 Change-Id: I06c485a7d0716201bd57d1f3be53668dddd7ec14 Reviewed-on: https://go-review.googlesource.com/22426 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
As a nice side-effect, this allows us to unify several code paths. The terminology (low, high, max, simple slice expr, full slice expr) is taken from the spec and the examples in the spec. This is a trial run. The plan, probably for Go 1.8, is to change slice expressions to use Node.List instead of OKEY, and to do some similar tree structure changes for other ops. Passes toolstash -cmp. No performance change. all.bash passes with GO_GCFLAGS=-newexport. Updates #15350 Change-Id: Ic1efdc36e79cdb95ae1636e9817a3ac8f83ab1ac Reviewed-on: https://go-review.googlesource.com/22425Reviewed-by:
-
Russ Cox authored
Update #15410 Change-Id: Iad3f2639aa7a67b11efc35a629e1893f7d87b957 Reviewed-on: https://go-review.googlesource.com/22430 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alex Brainman authored
Updates #15345 Change-Id: Iae35d3e378cbc8157ba1ff91e4971ed4515a5e5c Reviewed-on: https://go-review.googlesource.com/22394Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
