- 08 Nov, 2015 10 commits
-
-
Keith Randall authored
This change is the same as CL #9345 which was reverted, except for a small bug fix. The only change is to the body of sendDirect and its callsite. Also added a test. The problem was during a channel send operation. The target of the send was a sleeping goroutine waiting to receive. We basically do: 1) Read the destination pointer out of the sudog structure 2) Copy the value we're sending to that destination pointer Unfortunately, the previous change had a goroutine suspend point between 1 & 2 (the call to sendDirect). At that point the destination goroutine's stack could be copied (shrunk). The pointer we read in step 1 is no longer valid for step 2. Fixed by not allowing any suspension points between 1 & 2. I suspect the old code worked correctly basically by accident. Fixes #13169 The original 9345: This change removes the retry mechanism we use for buffered channels. Instead, any sender waking up a receiver or vice versa completes the full protocol with its counterpart. This means the counterpart does not need to relock the channel when it wakes up. (Currently buffered channels need to relock on wakeup.) For sends on a channel with waiting receivers, this change replaces two copies (sender->queue, queue->receiver) with one (sender->receiver). For receives on channels with a waiting sender, two copies are still required. This change unifies to a large degree the algorithm for buffered and unbuffered channels, simplifying the overall implementation. Fixes #11506 Change-Id: I57dfa3fc219cffa4d48301ee15fe5479299efa09 Reviewed-on: https://go-review.googlesource.com/16740Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I3975e10c2445e23c2798a7203a877ff2de3427c7 Reviewed-on: https://go-review.googlesource.com/14189Reviewed-by:
-
Dominik Honnef authored
Also change a -v print, for consistency. Fixes #12913 Change-Id: I6cc067d9f8dac66b1f9d1a675e0fbe0528371d0d Reviewed-on: https://go-review.googlesource.com/16737Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I0d0abbb9503c3a3c35d846fc0379836b2c483dea Reviewed-on: https://go-review.googlesource.com/15962Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I4fe1af48ec1cd8a23e2f7f2a0257dc989ff7aced Reviewed-on: https://go-review.googlesource.com/14235Reviewed-by:
-
Tamir Duberstein authored
Fixes #11994. Change-Id: Icee6ffa6e3a9d15b68b4ae9b2716d65ecbdba73a Reviewed-on: https://go-review.googlesource.com/16702Reviewed-by:
-
Dominik Honnef authored
Error doesn't take a format string and appends its own newline. Phrase the error like the other ones. Change-Id: Ic3af857e5d4890207c74a6eb59a0d1067b503e1b Reviewed-on: https://go-review.googlesource.com/16420Reviewed-by:
-
Brad Fitzpatrick authored
Updates to git rev 042ba42f (https://golang.org/cl/16734) This moves all the code for glueing the HTTP1 and HTTP2 transports together out of net/http and into x/net/http2 where others can use it, and where it has tests. Change-Id: I143ac8bb61eed36c87fd838b682ebb37b81b8c2c Reviewed-on: https://go-review.googlesource.com/16735 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Mathieu Lonjaret <mathieu.lonjaret@gmail.com> Reviewed-by:
-
Brad Fitzpatrick authored
This is needed now for subrepos to be able to conditionally use API symbols found only after Go 1.5. Change-Id: I91f8a1154e2a74008e8ca79490e3f12847f9c3b2 Reviewed-on: https://go-review.googlesource.com/16733 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
duffzero was changed to use X0 instead of AX in CL 14408. This was missed as part of that change. Change-Id: I72fb0114cfbc035b83bfaa8631d27e6740da2652 Reviewed-on: https://go-review.googlesource.com/16717 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
- 07 Nov, 2015 5 commits
-
-
Brad Fitzpatrick authored
To rev a179abb (handle Transport PING frames). Change-Id: I6e1eef2c9586c23f231803d9364d921248722f12 Reviewed-on: https://go-review.googlesource.com/16732Reviewed-by:
Blake Mizerany <blake.mizerany@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates to use new client pool abstraction. Change-Id: I3552018038ee8394d313d3253af337b07be211f6 Reviewed-on: https://go-review.googlesource.com/16730Reviewed-by:
-
Ian Lance Taylor authored
Other systems use pthread_sigmask. It was a mistake to use sigprocmask here. Change-Id: Ie045aa3f09cf035fcf807b7543b96fa5b847958a Reviewed-on: https://go-review.googlesource.com/16720Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
The GODEBUG option remains, for now, but only for turning it off. We'll decide what to do with it before release. This CL includes the dependent http2 change (https://golang.org/cl/16692) in the http2 bundle (h2_bundle.go). Updates golang/go#6891 Change-Id: If9723ef627c7ba4f7343dc8cb89ca88ef0fbcb10 Reviewed-on: https://go-review.googlesource.com/16693Reviewed-by:
-
Keith Randall authored
Make sure that we're moving or zeroing pointers atomically. Anything that is a multiple of pointer size and at least pointer aligned might have pointers in it. All the code looks ok except for the 1-pointer-sized moves. Fixes #13160 Update #12552 Change-Id: Ib97d9b918fa9f4cc5c56c67ed90255b7fdfb7b45 Reviewed-on: https://go-review.googlesource.com/16668Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 06 Nov, 2015 6 commits
-
-
Ilya Tocar authored
Use avx2 to compare 32 bytes per iteration. Results (haswell): name old time/op new time/op delta IndexByte32-6 15.5ns ± 0% 14.7ns ± 5% -4.87% (p=0.000 n=16+20) IndexByte4K-6 360ns ± 0% 183ns ± 0% -49.17% (p=0.000 n=19+20) IndexByte4M-6 384µs ± 0% 256µs ± 1% -33.41% (p=0.000 n=20+20) IndexByte64M-6 6.20ms ± 0% 4.18ms ± 1% -32.52% (p=0.000 n=19+20) IndexBytePortable32-6 73.4ns ± 5% 75.8ns ± 3% +3.35% (p=0.000 n=20+19) IndexBytePortable4K-6 5.15µs ± 0% 5.15µs ± 0% ~ (all samples are equal) IndexBytePortable4M-6 5.26ms ± 0% 5.25ms ± 0% -0.12% (p=0.000 n=20+18) IndexBytePortable64M-6 84.1ms ± 0% 84.1ms ± 0% -0.08% (p=0.012 n=18+20) Index32-6 352ns ± 0% 352ns ± 0% ~ (all samples are equal) Index4K-6 53.8µs ± 0% 53.8µs ± 0% -0.03% (p=0.000 n=16+18) Index4M-6 55.4ms ± 0% 55.4ms ± 0% ~ (p=0.149 n=20+19) Index64M-6 886ms ± 0% 886ms ± 0% ~ (p=0.108 n=20+20) IndexEasy32-6 80.3ns ± 0% 80.1ns ± 0% -0.21% (p=0.000 n=20+20) IndexEasy4K-6 426ns ± 0% 215ns ± 0% -49.53% (p=0.000 n=20+20) IndexEasy4M-6 388µs ± 0% 262µs ± 1% -32.42% (p=0.000 n=18+20) IndexEasy64M-6 6.20ms ± 0% 4.19ms ± 1% -32.47% (p=0.000 n=18+20) name old speed new speed delta IndexByte32-6 2.06GB/s ± 1% 2.17GB/s ± 5% +5.19% (p=0.000 n=18+20) IndexByte4K-6 11.4GB/s ± 0% 22.3GB/s ± 0% +96.45% (p=0.000 n=17+20) IndexByte4M-6 10.9GB/s ± 0% 16.4GB/s ± 1% +50.17% (p=0.000 n=20+20) IndexByte64M-6 10.8GB/s ± 0% 16.0GB/s ± 1% +48.19% (p=0.000 n=19+20) IndexBytePortable32-6 436MB/s ± 5% 422MB/s ± 3% -3.27% (p=0.000 n=20+19) IndexBytePortable4K-6 795MB/s ± 0% 795MB/s ± 0% ~ (p=0.940 n=17+18) IndexBytePortable4M-6 798MB/s ± 0% 799MB/s ± 0% +0.12% (p=0.000 n=20+18) IndexBytePortable64M-6 798MB/s ± 0% 798MB/s ± 0% +0.08% (p=0.011 n=18+20) Index32-6 90.9MB/s ± 0% 90.9MB/s ± 0% -0.00% (p=0.025 n=20+20) Index4K-6 76.1MB/s ± 0% 76.1MB/s ± 0% +0.03% (p=0.000 n=14+15) Index4M-6 75.7MB/s ± 0% 75.7MB/s ± 0% ~ (p=0.076 n=20+19) Index64M-6 75.7MB/s ± 0% 75.7MB/s ± 0% ~ (p=0.456 n=20+17) IndexEasy32-6 399MB/s ± 0% 399MB/s ± 0% +0.20% (p=0.000 n=20+19) IndexEasy4K-6 9.60GB/s ± 0% 19.02GB/s ± 0% +98.19% (p=0.000 n=20+20) IndexEasy4M-6 10.8GB/s ± 0% 16.0GB/s ± 1% +47.98% (p=0.000 n=18+20) IndexEasy64M-6 10.8GB/s ± 0% 16.0GB/s ± 1% +48.08% (p=0.000 n=18+20) Change-Id: I46075921dde9f3580a89544c0b3a2d8c9181ebc4 Reviewed-on: https://go-review.googlesource.com/16484Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> Reviewed-by:
Klaus Post <klauspost@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Duffcopy now uses X0, as of 5cf281a9. Teach the peephole optimizer that duffcopy clobbers X0 so that it does not rename registers use X0 across the duffcopy instruction. Fixes #13171 Change-Id: I389cbf1982cb6eb2f51e6152ac96736a8589f085 Reviewed-on: https://go-review.googlesource.com/16715 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
-
Marcel van Lohuizen authored
Change-Id: I53c196925fb86784b31dea799c27e79574d35fcc Reviewed-on: https://go-review.googlesource.com/16304Reviewed-by:
Marcel van Lohuizen <mpvl@golang.org>
-
Keith Randall authored
Revert for now until #13169 is understood. This reverts commit 8e496f1d. Change-Id: Ib3eb2588824ef47a2b6eb9e377a24e5c817fcc81 Reviewed-on: https://go-review.googlesource.com/16716Reviewed-by:
-
Ian Lance Taylor authored
They reportedly occur with LLVM 3.7 on FreeBSD ARM. Fixes #13139. Change-Id: Ia7d053a8662696b1984e81fbd1d908c951c35a98 Reviewed-on: https://go-review.googlesource.com/16667 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
Motivation: * Reader.skipUnread never reports io.ErrUnexpectedEOF. This is strange given that io.ErrUnexpectedEOF is given through Reader.Read if the user manually reads the file. * Reader.skipUnread fails to detect truncated files since io.Seeker is lazy about reporting errors. Thus, the behavior of Reader differs whether the input io.Reader also satisfies io.Seeker or not. To solve this, we seek to one before the end of the data section and always rely on at least one call to io.CopyN. If the tr.r satisfies io.Seeker, this is guarunteed to never read more than blockSize. Fixes #12557 Change-Id: I0ddddfc6bed0d74465cb7e7a02b26f1de7a7a279 Reviewed-on: https://go-review.googlesource.com/15175Reviewed-by:
-
- 05 Nov, 2015 19 commits
-
-
David du Colombier authored
TestBuildOutputToDevNull was added in CL 16585. However, copying to /dev/null couldn't work on Plan 9, because /dev/null is a regular file. Since it's not different from any other file, the logic in copyFile couldn't distinguish it from another, already existing, file, that we wouldn't want to overwrite. Change-Id: Ie8d353f318fedfc7cfb9541fed00a2397e232592 Reviewed-on: https://go-review.googlesource.com/16691Reviewed-by:
-
Michael Hudson-Doyle authored
sradi and sradi. hide the top bit of their immediate argument apart from the rest of it, but the code only handled the sradi case. I'm pretty sure this is the only instruction missing (a couple of the rotate instructions encode their immediate the same way but their handling looks OK). This fixes the failure of "GOARCH=amd64 ~/go/bin/go install -v runtime" as reported in the bug. Fixes #11987 Change-Id: I0cdefcd7a04e0e8fce45827e7054ffde9a83f589 Reviewed-on: https://go-review.googlesource.com/16710Reviewed-by:
-
David du Colombier authored
TestGoGenerateEnv was added in CL 16537. However, Plan 9 doesn't have the env command. Change-Id: I5f0c937a1b9b456dcea41ceac7865112f2f65c45 Reviewed-on: https://go-review.googlesource.com/16690Reviewed-by:
-
Austin Clements authored
These are now unused. Updates #11970. Change-Id: I43e5c4e5bcda9581bacc63364f96bb4855ab779f Reviewed-on: https://go-review.googlesource.com/16393Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently mallocgc detects if the GC is in a state where it can't assist, but also can't allocate uncontrolled and yields to help out the GC. This was a workaround for periods when we were trying to schedule the GC coordinator. It is no longer necessary because there is no GC coordinator and malloc can always assist with any GC transitions that are necessary. Updates #11970. Change-Id: I4f7beb7013e85e50ae99a3a8b0bb708ba49cbcd4 Reviewed-on: https://go-review.googlesource.com/16392Reviewed-by:
-
Austin Clements authored
This moves all of the mark 1 to mark 2 transition and mark termination to the mark done transition function. This means these transitions are now handled on the goroutine that detected mark completion. This also means that the GC coordinator and the background completion barriers are no longer used and various workarounds to yield to the coordinator are no longer necessary. These will be removed in follow-up commits. One consequence of this is that mark workers now need to be preemptible when performing the mark done transition. This allows them to stop the world and to perform the final clean-up steps of GC after restarting the world. They are only made preemptible while performing this transition, so if the worker findRunnableGCWorker would schedule isn't available, we didn't want to schedule it anyway. Fixes #11970. Change-Id: I9203a2d6287eeff62d589ec02ad9cb1e29ddb837 Reviewed-on: https://go-review.googlesource.com/16391Reviewed-by:
-
Austin Clements authored
Currently gcMarkDone takes basically no time, so it's okay to account the worker time after calling it. However, gcMarkDone is about to take potentially *much* longer because it may perform all of mark termination. Prepare for this by swapping the order so we account the time before calling gcMarkDone. Change-Id: I90c7df68192acfc4fd02a7254dae739dda4e2fcb Reviewed-on: https://go-review.googlesource.com/16390Reviewed-by:
-
Austin Clements authored
Currently the code for completion of mark 1/mark 2 is duplicated in background workers and assists. Factor this in to a single function that will serve as the transition function for concurrent mark. Change-Id: I4d9f697a15da0d349db3b34d56f3a220dd41d41b Reviewed-on: https://go-review.googlesource.com/16359Reviewed-by:
-
Austin Clements authored
Currently, findRunnableGCWorker will perform mark completion if there is no remaining work and no running workers. This used to be necessary to resolve a race in the transition from mark 1 to mark 2 where we would enter mark 2 with no mark work (and no dedicated workers), so no workers would run, so no worker would signal mark completion. However, we're about to make mark completion also perform the entire follow-on process, which includes mark termination. We really don't want to do that in the scheduler if it happens to detect completion. Conveniently, this hack is no longer necessary because we always enqueue root scanning work at the beginning of both mark 1 and mark 2, so a mark worker will always run. Hence, we can simply eliminate it. Change-Id: I3fc8f27c8da632f0fb732c9f6425e1f457f5652e Reviewed-on: https://go-review.googlesource.com/16358Reviewed-by:
-
Austin Clements authored
Currently, we don't start dedicated or fractional mark workers unless the mark 1 or mark 2 barriers have been cleared. One intended consequence of this is that no background workers run between the forEachP that disposes all gcWork caches and the beginning of mark 2. However, we (unintentionally) did not apply this restriction to idle mark workers. As a result, these can start in the interim between mark 1 completion and mark 2 starting. This explains why it was necessary to reset the root marking jobs using carefully ordered atomic writes when setting up mark 2. It also means that, even though we definitely enqueue work before starting mark 2, it may be drained by the time we reset the mark 2 barrier. If this happens, currently the only thing preventing the runtime from deadlocking is that the scheduler itself also checks for mark completion and will signal mark 2 completion. Were it not for the odd behavior of idle workers, this check in the scheduler would not be necessary. Clean all of this up and prepare to remove this check in the scheduler by applying the same restriction to starting idle mark workers. Change-Id: Ic1b479e1591bd7773dc27b320ca399a215603b5a Reviewed-on: https://go-review.googlesource.com/16631Reviewed-by:
-
Austin Clements authored
This moves all of GC initialization, sweep termination, and the transition to concurrent marking in to the off->mark transition function. This means it's now handled on the goroutine that detected the state exit condition. As a result, malloc no longer needs to Gosched() at the beginning of the GC cycle to prevent over-allocation while the GC is starting up because it will now *help* the GC to start up. The Gosched hack is still necessary during GC shutdown (this is easy to test by enabling gctrace and hitting Ctrl-S to block the gctrace output). At this point, the GC coordinator still handles later phases. This requires a small tweak to how we start the GC coordinator. Currently, starting the GC coordinator is best-effort and may fail if the coordinator is about to park from the previous cycle but hasn't yet. We fix this by replacing the park/ready to wake up the coordinator with a semaphore. This is temporary since the coordinator will be going away in a few commits. Updates #11970. Change-Id: I2c6a11c91e72dfbc59c2d8e7c66146dee9a444fe Reviewed-on: https://go-review.googlesource.com/16357Reviewed-by:
-
Austin Clements authored
This moves concurrent sweep termination from the coordinator to the off->mark transition. This allows it to be performed by all Gs attempting to start the GC. Updates #11970. Change-Id: I24428e8599a759398c2ef7ec996ba755a448f947 Reviewed-on: https://go-review.googlesource.com/16356Reviewed-by:
-
Austin Clements authored
This begins the conversion of the centralized GC coordinator to a decentralized state machine by introducing the internal API that triggers the first state transition from _GCoff to _GCmark (or _GCmarktermination). This change introduces the transition lock, the off->mark transition condition (which is very similar to shouldtriggergc()), and the general structure of a state transition. Since we're doing this conversion in stages, it then falls back to the GC coordinator to actually execute the cycle. We'll start moving logic out of the GC coordinator and in to transition functions next. This fixes a minor bug in gcstoptheworld debug mode where passing the heap trigger once could trigger multiple STW GCs. Updates #11970. Change-Id: I964087dd190a639eb5766398f8e1bbf8b352902f Reviewed-on: https://go-review.googlesource.com/16355Reviewed-by:
-
Austin Clements authored
For historical reasons we currently do a lot of the concurrent mark setup on the system stack. In fact, at this point the one and only thing that needs to happen on the system stack is the start-the-world. Clean up this code by lifting everything other than the start-the-world off the system stack. The diff for this change looks large, but the only code change is to narrow the systemstack call. Everything else is re-indentation. Change-Id: I1e03b8afc759fad726f2397b05a17d183c2713ce Reviewed-on: https://go-review.googlesource.com/16354Reviewed-by:
-
Austin Clements authored
We're about to split func gc across several functions, so lift the local variables it uses for tracking statistics and state across the cycle into the global "work" variable. Change-Id: Ie955f2f1758c7f5a5543ea1f3f33b222bc4b1d37 Reviewed-on: https://go-review.googlesource.com/16353Reviewed-by:
-
Austin Clements authored
Change-Id: I91cda8d88b0852cd0f868d33c594206bcca0c386 Reviewed-on: https://go-review.googlesource.com/16352Reviewed-by:
-
Ian Lance Taylor authored
Put 'r' first because that is the command, and 'c' is the modifier. Keep 'c' because it means to not warn when creating an archive. Drop 'u' because it is unnecessary and fails on Arch Linux. No test because this is only for gccgo (I tested it manually). Fixes #12310. Change-Id: Id740257fb1c347dfaa60f7d613af2897dae2c059 Reviewed-on: https://go-review.googlesource.com/16664 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ilya Tocar authored
Use AVX2 if possible. Results below (haswell): name old time/op new time/op delta CompareStringEqual-6 8.77ns ± 0% 8.63ns ± 1% -1.58% (p=0.000 n=20+19) CompareStringIdentical-6 5.02ns ± 0% 5.02ns ± 0% ~ (all samples are equal) CompareStringSameLength-6 7.51ns ± 0% 7.51ns ± 0% ~ (all samples are equal) CompareStringDifferentLength-6 1.56ns ± 0% 1.56ns ± 0% ~ (all samples are equal) CompareStringBigUnaligned-6 124µs ± 1% 105µs ± 5% -14.99% (p=0.000 n=20+18) CompareStringBig-6 112µs ± 1% 103µs ± 0% -7.87% (p=0.000 n=20+17) name old speed new speed delta CompareStringBigUnaligned-6 8.48GB/s ± 1% 9.98GB/s ± 5% +17.67% (p=0.000 n=20+18) CompareStringBig-6 9.37GB/s ± 1% 10.17GB/s ± 0% +8.54% (p=0.000 n=20+17) Change-Id: I1c949626dd2aaf9f633e3c888a9df71c82eed7e1 Reviewed-on: https://go-review.googlesource.com/16481Reviewed-by:
-
Keith Randall authored
This change removes the retry mechanism we use for buffered channels. Instead, any sender waking up a receiver or vice versa completes the full protocol with its counterpart. This means the counterpart does not need to relock the channel when it wakes up. (Currently buffered channels need to relock on wakeup.) For sends on a channel with waiting receivers, this change replaces two copies (sender->queue, queue->receiver) with one (sender->receiver). For receives on channels with a waiting sender, two copies are still required. This change unifies to a large degree the algorithm for buffered and unbuffered channels, simplifying the overall implementation. Fixes #11506 benchmark old ns/op new ns/op delta BenchmarkChanProdCons10 125 110 -12.00% BenchmarkChanProdCons0 303 284 -6.27% BenchmarkChanProdCons100 75.5 71.3 -5.56% BenchmarkChanContended 6452 6125 -5.07% BenchmarkChanNonblocking 11.5 11.0 -4.35% BenchmarkChanCreation 149 143 -4.03% BenchmarkChanSem 63.6 61.6 -3.14% BenchmarkChanUncontended 6390 6212 -2.79% BenchmarkChanSync 282 276 -2.13% BenchmarkChanProdConsWork10 516 506 -1.94% BenchmarkChanProdConsWork0 696 685 -1.58% BenchmarkChanProdConsWork100 470 469 -0.21% BenchmarkChanPopular 660427 660012 -0.06% Change-Id: I164113a56432fbc7cace0786e49c5a6e6a708ea4 Reviewed-on: https://go-review.googlesource.com/9345 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
Austin Clements <austin@google.com> Reviewed-by:
-
