- 27 May, 2016 15 commits
-
-
Austin Clements authored
Currently when the garbage collector frees stacks of dead goroutines in markrootFreeGStacks, it calls stackfree on a regular user stack. This is a problem, since stackfree manipulates the stack cache in the per-P mcache, so if it grows the stack or gets preempted in the middle of manipulating the stack cache (which are both possible since it's on a user stack), it can easily corrupt the stack cache. Fix this by calling markrootFreeGStacks on the system stack, so that all calls to stackfree happen on the system stack. To prevent this bug in the future, mark stack functions that manipulate the mcache as go:systemstack. Fixes #15853. Change-Id: Ic0d1c181efb342f134285a152560c3a074f14a3d Reviewed-on: https://go-review.googlesource.com/23511 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
For #15599. Change-Id: Icc2e58a3f314b7a098d78fe164ba36f5b2897de6 Reviewed-on: https://go-review.googlesource.com/23481 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
The current code, introduced after Go 1.6 to improve latency on low-bandwidth connections, sends 1 kB packets until 1 MB has been sent, and then sends 16 kB packets (the maximum record size). Unfortunately this decreases throughput for 1-16 MB responses by 20% or so. Following discussion on #15713, change cutoff to 128 kB sent and also grow the size allowed for successive packets: 1 kB, 2 kB, 3 kB, ..., 15 kB, 16 kB. This fixes the throughput problems: the overhead is now closer to 2%. I hope this still helps with latency but I don't have a great way to test it. At the least, it's not worse than Go 1.6. Comparing MaxPacket vs DynamicPacket benchmarks: name maxpkt time/op dyn. time/op delta Throughput/1MB-8 5.07ms ± 7% 5.21ms ± 7% +2.73% (p=0.023 n=16+16) Throughput/2MB-8 15.7ms ±201% 8.4ms ± 5% ~ (p=0.604 n=20+16) Throughput/4MB-8 14.3ms ± 1% 14.5ms ± 1% +1.53% (p=0.000 n=16+16) Throughput/8MB-8 26.6ms ± 1% 26.8ms ± 1% +0.47% (p=0.003 n=19+18) Throughput/16MB-8 51.0ms ± 1% 51.3ms ± 1% +0.47% (p=0.000 n=20+20) Throughput/32MB-8 100ms ± 1% 100ms ± 1% +0.24% (p=0.033 n=20+20) Throughput/64MB-8 197ms ± 0% 198ms ± 0% +0.56% (p=0.000 n=18+7) The small MB runs are bimodal in both cases, probably GC pauses. But there's clearly no general slowdown anymore. Fixes #15713. Change-Id: I5fc44680ba71812d24baac142bceee0e23f2e382 Reviewed-on: https://go-review.googlesource.com/23487Reviewed-by:
-
Russ Cox authored
Change-Id: Ia540c890767dcb001d3b3b55d98d9517b13b21da Reviewed-on: https://go-review.googlesource.com/23510Reviewed-by:
-
Russ Cox authored
New in Go 1.7 so still possible to change. This allows implementations not tied to *net.Dialer. Fixes #15748. Change-Id: I5fabbf13c7f1951c06587a4ccd120def488267ce Reviewed-on: https://go-review.googlesource.com/23489Reviewed-by:
-
Russ Cox authored
Requested during CL 23431. Change-Id: I513ae42166b3a9fcfe51231ff55c163ab672e7d2 Reviewed-on: https://go-review.googlesource.com/23485Reviewed-by:
David Chase <drchase@google.com>
-
Russ Cox authored
This was just storage for a linked list. Change-Id: I850e8db1e1f5e72410f5c904be9409179b56a94a Reviewed-on: https://go-review.googlesource.com/23484Reviewed-by:
-
Russ Cox authored
For #15810. Change-Id: Ib529808f664392feb9b36770f3d3d875fcb54528 Reviewed-on: https://go-review.googlesource.com/23488 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel Odeke authored
Document new behavior about signal name printing in panics as per CL golang.org/cl/22753. For #15810 Change-Id: I9c677d5dd779b41e82afa25e3c797d8e739600d3 Reviewed-on: https://go-review.googlesource.com/23493Reviewed-by:
Russ Cox <rsc@golang.org>
-
Russ Cox authored
The main check here is that liveness now crashes if it finds an instruction using a variable that should be tracked but is not. Comments and adjustments in nodarg to explain what's going on and to remove the "-1" argument added a few months ago, plus a sketch of a future simplification. The need for n.Orig in the earlier CL seems to have been an intermediate problem rather than fundamental: the new explanations in nodarg make clear that nodarg is not causing the problem I thought, and in fact now using n instead of n.Orig works fine in plive.go. Change-Id: I3f5cf9f6e4438a6d27abac7d490e7521545cd552 Reviewed-on: https://go-review.googlesource.com/23450 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Dmitri Shuralyov authored
This is a fixup change for commit 5cd29448 that added parsing of SCP-like addresses. To get the expected output from (*url.URL).String(), Path needs to be set, not RawPath. Add a test for this, since it has already regressed multiple times. Updates #11457. Change-Id: I806f5abbd3cf65e5bdcef01aab872caa8a5b8891 Reviewed-on: https://go-review.googlesource.com/23447 Run-TryBot: Andrew Gerrand <adg@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
As in the elimination of PHEAP|PPARAM in CL 23393, this is something the front end can trivially take care of and then not bother the back ends with. It also eliminates some suspect (and only lightly exercised) code paths in the back ends. I don't have a smoking gun for this one but it seems more clearly correct. Change-Id: I3b3f5e669b3b81d091ff1e2fb13226a6f14c69d5 Reviewed-on: https://go-review.googlesource.com/23431Reviewed-by:
-
Russ Cox authored
The liveness computation of parameters generally was never correct, but forcing all parameters to be live throughout the function covered up that problem. The new SSA back end is too clever: even though it currently keeps the parameter values live throughout the function, it may find optimizations that mean the current values are not written back to the original parameter stack slots immediately or ever (for example if a parameter is set to nil, SSA constant propagation may replace all later uses of the parameter with a constant nil, eliminating the need to write the nil value back to the stack slot), so the liveness code must now track the actual operations on the stack slots, exposing these problems. One small problem in the handling of arguments is that nodarg can return ONAME PPARAM nodes with adjusted offsets, so that there are actually multiple *Node pointers for the same parameter in the instruction stream. This might be possible to correct, but not in this CL. For now, we fix this by using n.Orig instead of n when considering PPARAM and PPARAMOUT nodes. The major problem in the handling of arguments is general confusion in the liveness code about the meaning of PPARAM|PHEAP and PPARAMOUT|PHEAP nodes, especially as contrasted with PAUTO|PHEAP. The difference between these two is that when a local variable "moves" to the heap, it's really just allocated there to start with; in contrast, when an argument moves to the heap, the actual data has to be copied there from the stack at the beginning of the function, and when a result "moves" to the heap the value in the heap has to be copied back to the stack when the function returns This general confusion is also present in the SSA back end. The PHEAP bit worked decently when I first introduced it 7 years ago (!) in 391425ae. The back end did nothing sophisticated, and in particular there was no analysis at all: no escape analysis, no liveness analysis, and certainly no SSA back end. But the complications caused in the various downstream consumers suggest that this should be a detail kept mainly in the front end. This CL therefore eliminates both the PHEAP bit and even the idea of "heap variables" from the back ends. First, it replaces the PPARAM|PHEAP, PPARAMOUT|PHEAP, and PAUTO|PHEAP variable classes with the single PAUTOHEAP, a pseudo-class indicating a variable maintained on the heap and available by indirecting a local variable kept on the stack (a plain PAUTO). Second, walkexpr replaces all references to PAUTOHEAP variables with indirections of the corresponding PAUTO variable. The back ends and the liveness code now just see plain indirected variables. This may actually produce better code, but the real goal here is to eliminate these little-used and somewhat suspect code paths in the back end analyses. The OPARAM node type goes away too. A followup CL will do the same to PPARAMREF. I'm not sure that the back ends (SSA in particular) are handling those right either, and with the framework established in this CL that change is trivial and the result clearly more correct. Fixes #15747. Change-Id: I2770b1ce3cbc93981bfc7166be66a9da12013d74 Reviewed-on: https://go-review.googlesource.com/23393Reviewed-by:
-
Alex Brainman authored
The problem was introduced by the recent filepath.Join change. Fixes #14949 Change-Id: I7ee52f210e12bbb1369e308e584ddb2c7766e095 Reviewed-on: https://go-review.googlesource.com/23240 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
The cgo tool generates compiler errors to find out what kind of name it is using. Turning on optimization can confuse that process by producing new unexpected messages. Fixes #14669. Change-Id: Idc8e35fd259711ecc9638566b691c11d17140325 Reviewed-on: https://go-review.googlesource.com/23231 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 26 May, 2016 17 commits
-
-
Keith Randall authored
Add a test which compiles a function and checks the generated assembly to make sure certain patterns are present. This test allows us to do white box tests of the compiler to make sure optimizations don't regress. Added a few simple tests for now. More to come. Change-Id: I4ab5ce5d95b9e04e7d0d9328ffae47b8d1f95e74 Reviewed-on: https://go-review.googlesource.com/23403Reviewed-by:
-
Quentin Smith authored
Decoding a JSON message does not touch unspecified or null fields; always use a new underlying struct to prevent old field values from sticking around. Fixes: #14640 Change-Id: Ica78c208ce104e2cdee1d4e92bf58596ea5587c8 Reviewed-on: https://go-review.googlesource.com/23483Reviewed-by:
-
Keith Randall authored
Increases coverage of generic.rules from 72% to 84%. Change-Id: I1b139aeeb6410d025d49cbe4e4601f6f935ce1e5 Reviewed-on: https://go-review.googlesource.com/23490Reviewed-by:
Todd Neal <todd@tneal.org>
-
Keith Randall authored
When rules are generated with -log, log rule application to a file. The file is opened in append mode so multiple calls to the compiler union their logs. Change-Id: Ib35c7c85bf58e5909ea9231043f8cbaa6bf278b7 Reviewed-on: https://go-review.googlesource.com/23406Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Josh Bleecher Snyder authored
domorder has some non-obvious useful properties that we’re relying on in cse. Document them and provide an argument that they hold. While we’re here, do some minor renaming. The argument is a re-working of a private email exchange with Todd Neal and David Chase. Change-Id: Ie154e0521bde642f5f11e67fc542c5eb938258be Reviewed-on: https://go-review.googlesource.com/23449 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Marcel van Lohuizen authored
Change-Id: I3ede8098f405de5d88e51c8370d3b68446d40744 Reviewed-on: https://go-review.googlesource.com/23428 Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Russ Cox authored
I'm glad my CL fixed the library use case inside Google. It fixes neither of the two tests here. Change-Id: Ica91722dced8955a0a8ba3aad3d288816b46564e Reviewed-on: https://go-review.googlesource.com/23482 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
This has a minor performance cost, but far less than is being gained by SSA. As an experiment, enable it during the Go 1.7 beta. Having frame pointers on by default makes Linux's perf, Intel VTune, and other profilers much more useful, because it lets them gather a stack trace efficiently on profiling events. (It doesn't help us that much, since when we walk the stack we usually need to look up PC-specific information as well.) Fixes #15840. Change-Id: I4efd38412a0de4a9c87b1b6e5d11c301e63f1a2a Reviewed-on: https://go-review.googlesource.com/23451 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Follow-up cleanup to https://golang.org/cl/23424/ . Change-Id: Ifb05c1ff5327df6bc5f4cbc554e18363293f7960 Reviewed-on: https://go-review.googlesource.com/23446Reviewed-by:
Marcel van Lohuizen <mpvl@golang.org>
-
David Crawshaw authored
Fixes #15832 Change-Id: I6f3f45e3c21edd0e093ecb1d8a067907863478f5 Reviewed-on: https://go-review.googlesource.com/23441Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Russ Cox authored
It is timing out on the dashboard. (We enabled it as an experiment to see if it was still broken. Looks that way.) Change-Id: I425b7e54a2ab95b623ab7a15554b4173078f75e2 Reviewed-on: https://go-review.googlesource.com/23480Reviewed-by:
-
Austin Clements authored
The irregular calling convention for defers currently incorrectly manages the BP if frame pointers are enabled. Specifically, jmpdefer manipulates the SP as if its own caller, deferreturn, had returned. However, it does not manipulate the BP to match. As a result, when a BP-based traceback happens during a deferred function call, it unwinds to the function that performed the defer and then thinks that function called itself in an infinite regress. Fix this by making jmpdefer manipulate the BP as if deferreturn had actually returned. Fixes #12968. Updates #15840. Change-Id: Ic9cc7c863baeaf977883ed0c25a7e80e592cf066 Reviewed-on: https://go-review.googlesource.com/23457Reviewed-by:
-
Austin Clements authored
The offsets computed by the DWARF expressions for local variables currently don't account for the extra stack slot used by the frame pointer when GOEXPERIMENT=framepointer is enabled. Fix this by adding the extra stack slot to the offset. This fixes TestGdbPython with GOEXPERIMENT=framepointer. Updates #15840. Change-Id: I1b2ebb2750cd22266f4a89ec8d9e8bfa05fabd19 Reviewed-on: https://go-review.googlesource.com/23458 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
A few other architectures have already defined a NOFRAME flag. Use it to disable frame pointer code on a few very low-level functions that must behave like Windows code. Makes the failing os/signal test pass on a Windows gomote. Change-Id: I982365f2c59a0aa302b4428c970846c61027cf3e Reviewed-on: https://go-review.googlesource.com/23456Reviewed-by:
-
Ilya Tocar authored
AVX2 variant reads next blocks while calculating current block. Avoid reading past the end of data, by switching back to original, for last blocks. Fixes #15617. Change-Id: I04fa2d83f1b47995117c77b4a3d403a7dff594d4 Reviewed-on: https://go-review.googlesource.com/23138Reviewed-by:
-
Russ Cox authored
I have been running this patch inside Google against Go 1.6 for the last month. The new tests will probably break the builders but let's see exactly how they break. Change-Id: Ia65cf7d3faecffeeb4b06e9b80875c0e57d86d9e Reviewed-on: https://go-review.googlesource.com/23452Reviewed-by:
-
Robert Griesemer authored
The importer had several bugs with respect to labels and gotos: - it didn't create a new ONAME node for label names (label dcl, goto, continue, and break) - it overwrote the symbol for gotos with the dclstack - it didn't set the dclstack for labels In the process changed export format slightly to always assume a label name for labels and gotos, and never assume a label for fallthroughs. For fallthroughs and switch cases, now also set Xoffset like in the parser. (Not setting it, i.e., using 0 was ok since this is only used for verifying correct use of fallthroughs, which was checked already. But it's an extra level of verification of the import.) Fixes #15838. Change-Id: I3637f6314b8651c918df0c8cd70cd858c92bd483 Reviewed-on: https://go-review.googlesource.com/23445 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 25 May, 2016 8 commits
-
-
Seth Vargo authored
This commit adds missing status codes: * 102 - Processing * 207 - Multi-Status * 208 - Already Reported * 226 - IM Used * 308 - Permanent Redirect * 422 - Unprocessable Entity * 423 - Locked * 424 - Failed Dependency * 426 - Upgrade Required * 506 - Variant Also Negotiates * 507 - Insufficient Storage * 508 - Loop Detected * 510 - Not Extended * 511 - Network Authentication Required Change-Id: Ife0e5b064f4b1e3542d2fd41abc9e7b1e410b644 Reviewed-on: https://go-review.googlesource.com/23090Reviewed-by:
-
Ian Lance Taylor authored
Acquire and release the TSAN synchronization point when calling malloc, just as we do when calling any other C function. If we don't do this, TSAN will report false positive errors about races calling malloc and free. We used to have a special code path for malloc and free, going through the runtime functions cmalloc and cfree. The special code path for cfree was no longer used even before this CL. This CL stops using the special code path for malloc, because there is no place along that path where we could conditionally insert the TSAN synchronization. This CL removes the support for the special code path for both functions. Instead, cgo now automatically generates the malloc function as though it were referenced as C.malloc. We need to automatically generate it even if C.malloc is not called, even if malloc and size_t are not declared, to support cgo-provided functions like C.CString. Change-Id: I829854ec0787a80f33fa0a8a0dc2ee1d617830e2 Reviewed-on: https://go-review.googlesource.com/23260Reviewed-by:
-
Russ Cox authored
This makes GOEXPERIMENT=framepointer, GOOS=darwin, and buildmode=carchive coexist. Change-Id: I9f6fb2f0f06f27df683e5b51f2fa55cd21872453 Reviewed-on: https://go-review.googlesource.com/23454Reviewed-by:
-
Austin Clements authored
Currently scanstack obtains its own gcWork from the P for the duration of the stack scan and then, if called during mark termination, disposes the gcWork. However, this means that the number of workbufs allocated will be at least the number of stacks scanned during mark termination, which may be very high (especially during a STW GC). This happens because, in steady state, each scanstack will obtain a fresh workbuf (either from the empty list or by allocating it), fill it with the scan results, and then dispose it to the full list. Nothing is consuming from the full list during this (and hence nothing is recycling them to the empty list), so the length of the full list by the time mark termination starts draining it is at least the number of stacks scanned. Fix this by pushing the gcWork acquisition up the stack to either the gcDrain that calls markroot that calls scanstack (which batches across many stack scans and is the path taken during STW GC) or to newstack (which is still a single scanstack call, but this is roughly bounded by the number of Ps). This fix reduces the workbuf allocation for the test program from issue #15319 from 213 MB (roughly 2KB * 1e5 goroutines) to 10 MB. Fixes #15319. Note that there's potentially a similar issue in write barriers during mark 2. Fixing that will be more difficult since there's no broader non-preemptible context, but it should also be less of a problem since the full list is being drained during mark 2. Some overall improvements in the go1 benchmarks, plus the usual noise. No significant change in the garbage benchmark (time/op or GC memory). name old time/op new time/op delta BinaryTree17-12 2.54s ± 1% 2.51s ± 1% -1.09% (p=0.000 n=20+19) Fannkuch11-12 2.12s ± 0% 2.17s ± 0% +2.18% (p=0.000 n=19+18) FmtFprintfEmpty-12 45.1ns ± 1% 45.2ns ± 0% ~ (p=0.078 n=19+18) FmtFprintfString-12 127ns ± 0% 128ns ± 0% +1.08% (p=0.000 n=19+16) FmtFprintfInt-12 125ns ± 0% 122ns ± 1% -2.71% (p=0.000 n=14+18) FmtFprintfIntInt-12 196ns ± 0% 190ns ± 1% -2.91% (p=0.000 n=12+20) FmtFprintfPrefixedInt-12 196ns ± 0% 194ns ± 1% -0.94% (p=0.000 n=13+18) FmtFprintfFloat-12 253ns ± 1% 251ns ± 1% -0.86% (p=0.000 n=19+20) FmtManyArgs-12 807ns ± 1% 784ns ± 1% -2.85% (p=0.000 n=20+20) GobDecode-12 7.13ms ± 1% 7.12ms ± 1% ~ (p=0.351 n=19+20) GobEncode-12 5.89ms ± 0% 5.95ms ± 0% +0.94% (p=0.000 n=19+19) Gzip-12 219ms ± 1% 221ms ± 1% +1.35% (p=0.000 n=18+20) Gunzip-12 37.5ms ± 1% 37.4ms ± 0% ~ (p=0.057 n=20+19) HTTPClientServer-12 81.4µs ± 4% 81.9µs ± 3% ~ (p=0.118 n=17+18) JSONEncode-12 15.7ms ± 1% 15.8ms ± 1% +0.73% (p=0.000 n=17+18) JSONDecode-12 57.9ms ± 1% 57.2ms ± 1% -1.34% (p=0.000 n=19+19) Mandelbrot200-12 4.12ms ± 1% 4.10ms ± 0% -0.33% (p=0.000 n=19+17) GoParse-12 3.22ms ± 2% 3.25ms ± 1% +0.72% (p=0.000 n=18+20) RegexpMatchEasy0_32-12 70.6ns ± 1% 71.1ns ± 2% +0.63% (p=0.005 n=19+20) RegexpMatchEasy0_1K-12 240ns ± 0% 239ns ± 1% -0.59% (p=0.000 n=19+20) RegexpMatchEasy1_32-12 71.3ns ± 1% 71.3ns ± 1% ~ (p=0.844 n=17+17) RegexpMatchEasy1_1K-12 384ns ± 2% 371ns ± 1% -3.45% (p=0.000 n=19+20) RegexpMatchMedium_32-12 109ns ± 1% 108ns ± 2% -0.48% (p=0.029 n=19+19) RegexpMatchMedium_1K-12 34.3µs ± 1% 34.5µs ± 2% ~ (p=0.160 n=18+20) RegexpMatchHard_32-12 1.79µs ± 9% 1.72µs ± 2% -3.83% (p=0.000 n=19+19) RegexpMatchHard_1K-12 53.3µs ± 4% 51.8µs ± 1% -2.82% (p=0.000 n=19+20) Revcomp-12 386ms ± 0% 388ms ± 0% +0.72% (p=0.000 n=17+20) Template-12 62.9ms ± 1% 62.5ms ± 1% -0.57% (p=0.010 n=18+19) TimeParse-12 325ns ± 0% 331ns ± 0% +1.84% (p=0.000 n=18+19) TimeFormat-12 338ns ± 0% 343ns ± 0% +1.34% (p=0.000 n=18+20) [Geo mean] 52.7µs 52.5µs -0.42% Change-Id: Ib2d34736c4ae2ec329605b0fbc44636038d8d018 Reviewed-on: https://go-review.googlesource.com/23391 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Also mark it go:systemstack and explain why. Change-Id: I88baf22741c04012ba2588d8e03dd3801d19b5c0 Reviewed-on: https://go-review.googlesource.com/23390 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
No code changes. Fixes #15835. Change-Id: Ibae3f20882f976babc4093df5e9fea0b2cf0e9d9 Reviewed-on: https://go-review.googlesource.com/23443Reviewed-by:
Alan Donovan <adonovan@google.com>
-
David Crawshaw authored
For #15673 Change-Id: I3ce8d4016854d41860c5a9f05a54cda3de49f337 Reviewed-on: https://go-review.googlesource.com/23430Reviewed-by:
-
Marcel van Lohuizen authored
shortens code and gives an example of the use of Run. Change-Id: I75ffaf762218a589274b4b62e19022e31e805d1b Reviewed-on: https://go-review.googlesource.com/23424Reviewed-by:
-
