- 02 Aug, 2016 5 commits
-
-
Chris Broadfoot authored
Change-Id: Icf861dd28bfe29a2e4b90529e53644b43b6f7969 Reviewed-on: https://go-review.googlesource.com/25368Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Chris Broadfoot authored
Change-Id: Ifb9647fa9817ed57aa4835a35a05020aba00a24e
-
Brad Fitzpatrick authored
This was previously fixed in https://golang.org/cl/21497 but not enough. Fixes #16523 Change-Id: I678543a656304c82d654e25e12fb094cd6cc87e8 Reviewed-on: https://go-review.googlesource.com/25330 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Fixes #16550 Updates #15908 Change-Id: Ic951080dbc88f96e4c00cdb3ffe24a5c03079efd Reviewed-on: https://go-review.googlesource.com/25389Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Brad Fitzpatrick authored
Updates bundled http2 to x/net/http2 rev 28d1bd4f for: http2: make Transport work around mod_h2 bug https://golang.org/cl/25362 http2: don't ignore DATA padding in flow control https://golang.org/cl/25382 Updates #16519 Updates #16556 Updates #16481 Change-Id: I51f5696e977c91bdb2d80d2d56b8a78e3222da3f Reviewed-on: https://go-review.googlesource.com/25388Reviewed-by: Chris Broadfoot <cbro@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 29 Jul, 2016 1 commit
-
-
Cherry Zhang authored
SSA compiler on AMD64 may spill Duff-adjusted address as scalar. If the object is on stack and the stack moves, the spilled address become invalid. Making the spill pointer-typed does not work. The Duff-adjusted address points to the memory before the area to be zeroed and may be invalid. This may cause stack scanning code panic. Fix it by doing Duff-adjustment in genValue, so the intermediate value is not seen by the reg allocator, and will not be spilled. Add a test to cover both cases. As it depends on allocation, it may be not always triggered. Fixes #16515. Change-Id: Ia81d60204782de7405b7046165ad063384ede0db Reviewed-on: https://go-review.googlesource.com/25309 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
- 28 Jul, 2016 1 commit
-
-
Brad Fitzpatrick authored
Updates #16396 Change-Id: I7b4f85610e66f2c77c17cf8898cc41d81b2efc8c Reviewed-on: https://go-review.googlesource.com/25283Reviewed-by: Chris Broadfoot <cbro@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 27 Jul, 2016 2 commits
-
-
Rhys Hiltner authored
Mutator goroutines that allocate memory during the concurrent mark phase are required to spend some time assisting the garbage collector. The magnitude of this mandatory assistance is proportional to the goroutine's allocation debt and subject to the assistance ratio as calculated by the pacer. When assisting the garbage collector, a mutator goroutine will go beyond paying off its allocation debt. It will build up extra credit to amortize the overhead of the assist. In fast-allocating applications with high assist ratios, building up this credit can take the affected goroutine's entire time slice. Reduce the penalty on each goroutine being selected to assist the GC in two ways, to spread the responsibility more evenly. First, do a consistent amount of extra scan work without regard for the pacer's assistance ratio. Second, reduce the magnitude of the extra scan work so it can be completed within a few hundred microseconds. Commentary on gcOverAssistWork is by Austin Clements, originally in https://golang.org/cl/24704 Updates #14812 Fixes #16432 Change-Id: I436f899e778c20daa314f3e9f0e2a1bbd53b43e1 Reviewed-on: https://go-review.googlesource.com/25155 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Brad Fitzpatrick authored
Fixes #16505 Change-Id: I0afabcc8b1be3a5dbee59946b0c44d4c00a28d71 Reviewed-on: https://go-review.googlesource.com/25280 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
- 26 Jul, 2016 7 commits
-
-
Brad Fitzpatrick authored
https://golang.org/cl/25233 was detecting the OS X release at compile time, not run time. Detect it at run time instead. Fixes #16473 (again) Change-Id: I6bec4996e57aa50c52599c165aa6f1fae7423fa7 Reviewed-on: https://go-review.googlesource.com/25281 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev 6a513af for: http2: return flow control for closed streams https://golang.org/cl/25231 http2: make Transport prefer HTTP response header recv before body write error https://golang.org/cl/24984 http2: make Transport treat "Connection: close" the same as Request.Close https://golang.org/cl/24982 Fixes golang/go#16481 Change-Id: Iaddb166387ca2df1cfbbf09a166f8605578bec49 Reviewed-on: https://go-review.googlesource.com/25282 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Austin Clements authored
Currently the pprof package gives almost no guidance for how to use it and, despite the standard boilerplate used to create CPU and memory profiles, this boilerplate appears nowhere in the pprof documentation. Update the pprof package documentation to give the standard boilerplate in a form people can copy, paste, and tweak. This boilerplate is based on rsc's 2011 blog post on profiling Go programs at https://blog.golang.org/profiling-go-programs, which is where I always go when I need to copy-paste the boilerplate. Change-Id: I74021e494ea4dcc6b56d6fb5e59829ad4bb7b0be Reviewed-on: https://go-review.googlesource.com/25182Reviewed-by: Rick Hudson <rlh@golang.org>
-
Brad Fitzpatrick authored
Conservative fix for the OS X 10.8 crash. We can unify them back together during the Go 1.8 dev cycle. Fixes #16473 Change-Id: If07228deb2be36093dd324b3b3bcb31c23a95035 Reviewed-on: https://go-review.googlesource.com/25233 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Jack Lindamood authored
Adds a test case for calling context.WithDeadline() where the deadline exists in the past. This change increases the code coverage of the context package. Change-Id: Ib486bf6157e779fafd9dab2b7364cdb5a06be36e Reviewed-on: https://go-review.googlesource.com/25007Reviewed-by: Sameer Ajmani <sameer@golang.org> Run-TryBot: Sameer Ajmani <sameer@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
From at least Go 1.4 to Go 1.6, Transport.RoundTrip would return the error value from net.Conn.Read directly when the initial Read (1 byte Peek) failed while reading the HTTP response, if a request was outstanding. While never a documented or tested promise, Go 1.7 changed the behavior (starting at https://golang.org/cl/23160). This restores the old behavior and adds a test (but no documentation promises yet) while keeping the fix for spammy logging reported in #15446. This looks larger than it is: it just changes errServerClosedConn from a variable to a type, where the type preserves the underlying net.Conn.Read error, for unwrapping later in Transport.RoundTrip. Fixes #16465 Change-Id: I6fa018991221e93c0cfe3e4129cb168fbd98bd27 Reviewed-on: https://go-review.googlesource.com/25153Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
Fixes #16362 Change-Id: I676718a1149ed2f3ff80cb031e25de7043805399 Reviewed-on: https://go-review.googlesource.com/25157Reviewed-by: Rob Pike <r@golang.org>
-
- 25 Jul, 2016 1 commit
-
-
Joe Tsai authored
Fixes #16489 Change-Id: I13e2ed6de59102f977566de637d8d09b4e541980 Reviewed-on: https://go-review.googlesource.com/25200Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 22 Jul, 2016 1 commit
-
-
Brad Fitzpatrick authored
Noticed when investigating a separate issue. No external bug report or repro yet. Change-Id: I8a1641a43163f22b09accd3beb25dd9e2a68a238 Reviewed-on: https://go-review.googlesource.com/25152 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 21 Jul, 2016 6 commits
-
-
Chris Broadfoot authored
Change-Id: Iaef13003979c68926c260c415d6074a50ae137b2 Reviewed-on: https://go-review.googlesource.com/25142 Run-TryBot: Chris Broadfoot <cbro@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Chris Broadfoot authored
Change-Id: I2511c3f7583887b641c9b3694aae54789fbc5342
-
Brad Fitzpatrick authored
It was removed in upstream Chrome https://codereview.chromium.org/2016863004 Rather than update to the latest version, make the minimal change for Go 1.7 and change the "showToUser" boolean from true to false. Tested by hand that it goes away after this change. Updates #16247 Change-Id: I051f49da878e554b1a34a88e9abc70ab50e18780 Reviewed-on: https://go-review.googlesource.com/25117Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Chase authored
This is: (1) a simple trick that cuts the number of phi-nodes (temporarily) inserted into the ssa representation by a factor of 10, and can cut the user time to compile tricky inputs like gogo/protobuf tests from 13 user minutes to 9.5, and memory allocation from 3.4GB to 2.4GB. (2) a fix to sparse lookup, that does not rely on an assumption proven false by at least one pathological input "etldlen". These two changes fix unrelated compiler performance bugs, both necessary to obtain good performance compiling etldlen. Without them it takes 20 minutes or longer, with them it completes in 2 minutes, without a gigantic memory footprint. Updates #16407 Change-Id: Iaa8aaa8c706858b3d49de1c4865a7fd79e6f4ff7 Reviewed-on: https://go-review.googlesource.com/23136Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
entry: x = MOVQconst [7] ... b1: goto b2 b2: v = Phi(x, y, z) Transform that program to: entry: ... b1: x = MOVQconst [7] goto b2 b2: v = Phi(x, y, z) This CL moves constant-generating instructions used by a phi to the appropriate immediate predecessor of the phi's block. We used to put all constants in the entry block. Unfortunately, in large functions we have lots of constants at the start of the function, all of which are used by lots of phis throughout the function. This leads to the constants being live through most of the function (especially if there is an outer loop). That's an O(n^2) problem. Note that most of the non-phi uses of constants have already been folded into instructions (ADDQconst, MOVQstoreconst, etc.). This CL may be generally useful for other instances of compiler slowness, I'll have to check. It may cause some programs to run slower, but probably not by much, as rematerializeable values like these constants are allocated late (not at their originally scheduled location) anyway. This CL is definitely a minimal change that can be considered for 1.7. We probably want to do a better job in the tighten pass generally, not just for phi args. Leaving that for 1.8. Update #16407 Change-Id: If112a8883b4ef172b2f37dea13e44bda9346c342 Reviewed-on: https://go-review.googlesource.com/25046 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Ian Lance Taylor authored
The omission of this instruction could confuse the traceback code if a SIGPROF occurred during a signal handler. The traceback code would trace up to sigtramp, but would then get confused because it would see a PC address that did not appear to be in the function. Fixes #16453. Change-Id: I2b3d53e0b272fb01d9c2cb8add22bad879d3eebc Reviewed-on: https://go-review.googlesource.com/25104Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
- 20 Jul, 2016 4 commits
-
-
Austin Clements authored
Most operations need an upper bound on the physical page size, which is what sys.PhysPageSize is for (this is checked at runtime init on Linux). However, a few operations need a *lower* bound on the physical page size. Introduce a "minPhysPageSize" constant to act as this lower bound and use it where it makes sense: 1) In addrspace_free, we have to query each page in the given range. Currently we increment by the upper bound on the physical page size, which means we may skip over pages if the true size is smaller. Worse, we currently pass a result buffer that only has enough room for one page. If there are actually multiple pages in the range passed to mincore, the kernel will overflow this buffer. Fix these problems by incrementing by the lower-bound on the physical page size and by passing "1" for the length, which the kernel will round up to the true physical page size. 2) In the write barrier, the bad pointer check tests for pointers to the first physical page, which are presumably small integers masquerading as pointers. However, if physical pages are smaller than we think, we may have legitimate pointers below sys.PhysPageSize. Hence, use minPhysPageSize for this test since pointers should never fall below that. In particular, this applies to ARM64 and MIPS. The runtime is configured to use 64kB pages on ARM64, but by default Linux uses 4kB pages. Similarly, the runtime assumes 16kB pages on MIPS, but both 4kB and 16kB kernel configurations are common. This also applies to ARM on systems where the runtime is recompiled to deal with a larger page size. It is also a step toward making the runtime use only a dynamically-queried page size. Change-Id: I1fdfd18f6e7cbca170cc100354b9faa22fde8a69 Reviewed-on: https://go-review.googlesource.com/25020Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Austin Clements <austin@google.com>
-
Dmitry Vyukov authored
The leak was reported internally on a sever canary that runs for days. After a day server consumes 5.6GB, after 6 days -- 12.2GB. The leak is exposed by the added benchmark. The leak is fixed upstream in : http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_rtl_thread.cc?view=diff&r1=276102&r2=276103&pathrev=276103 Fixes #16441 Change-Id: I9d4f0adef48ca6cf2cd781b9a6990ad4661ba49b Reviewed-on: https://go-review.googlesource.com/25091Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
-
Ian Lance Taylor authored
When a non-Go thread calls into Go, the runtime needs an M to run the Go code. The runtime keeps a list of extra M's available. When the last extra M is allocated, the needextram field is set to tell it to allocate a new extra M as soon as it is running in Go. This ensures that an extra M will always be available for the next thread. However, if many threads need an extra M at the same time, this serializes them all. One thread will get an extra M with the needextram field set. All the other threads will see that there is no M available and will go to sleep. The one thread that succeeded will create a new extra M. One lucky thread will get it. All the other threads will see that there is no M available and will go to sleep. The effect is thundering herd, as all the threads looking for an extra M go through the process one by one. This seems to have a particularly bad effect on the FreeBSD scheduler for some reason. With this change, we track the number of threads waiting for an M, and create all of them as soon as one thread gets through. This still means that all the threads will fight for the lock to pick up the next M. But at least each thread that gets the lock will succeed, instead of going to sleep only to fight again. This smooths out the performance greatly on FreeBSD, reducing the average wall time of `testprogcgo CgoCallbackGC` by 74%. On GNU/Linux the average wall time goes down by 9%. Fixes #13926 Fixes #16396 Change-Id: I6dc42a4156085a7ed4e5334c60b39db8f8ef8fea Reviewed-on: https://go-review.googlesource.com/25047 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Brad Fitzpatrick authored
This copies the frozen wording from the log/syslog package. Fixes #16436 Change-Id: If5d478023328925299399f228d8aaf7fb117c1b4 Reviewed-on: https://go-review.googlesource.com/25080Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 18 Jul, 2016 8 commits
-
-
Austin Clements authored
Change-Id: Ia1c2ebcd2ccf7b98d89b378633bf4fc435d2364d Reviewed-on: https://go-review.googlesource.com/25019Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
Rather than saying "stop-the-world", say "garbage collection pauses". Change-Id: Ifb2931781ab3094e04bea93f01f18f1acb889bdc Reviewed-on: https://go-review.googlesource.com/25018Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Ian Lance Taylor authored
Updates #16354 Updates #16272 Change-Id: I73e8df40621a0a17a1990f3b10ea996f4fa738aa Reviewed-on: https://go-review.googlesource.com/25014 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Chris Broadfoot authored
Change-Id: I5473071f672f8352fbd3352e158d5be12823b58a Reviewed-on: https://go-review.googlesource.com/25017 Run-TryBot: Chris Broadfoot <cbro@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Chris Broadfoot authored
Change-Id: Ib33d7fb529aafcaf8ca7d43b2c9480f30d5c28cc Reviewed-on: https://go-review.googlesource.com/25011Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Because, * The CGI spec defines that incoming request header "Foo: Bar" maps to environment variable HTTP_FOO == "Bar". (see RFC 3875 4.1.18) * The HTTP_PROXY environment variable is conventionally used to configure the HTTP proxy for HTTP clients (and is respected by default for Go's net/http.Client and Transport) That means Go programs running in a CGI environment (as a child process under a CGI host) are vulnerable to an incoming request containing "Proxy: attacker.com:1234", setting HTTP_PROXY, and changing where Go by default proxies all outbound HTTP requests. This is CVE-2016-5386, aka https://httpoxy.org/ Fixes #16405 Change-Id: I6f68ade85421b4807785799f6d98a8b077e871f0 Reviewed-on: https://go-review.googlesource.com/25010 Run-TryBot: Chris Broadfoot <cbro@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org> Reviewed-on: https://go-review.googlesource.com/25013
-
Brad Fitzpatrick authored
Because, * The CGI spec defines that incoming request header "Foo: Bar" maps to environment variable HTTP_FOO == "Bar". (see RFC 3875 4.1.18) * The HTTP_PROXY environment variable is conventionally used to configure the HTTP proxy for HTTP clients (and is respected by default for Go's net/http.Client and Transport) That means Go programs running in a CGI environment (as a child process under a CGI host) are vulnerable to an incoming request containing "Proxy: attacker.com:1234", setting HTTP_PROXY, and changing where Go by default proxies all outbound HTTP requests. This is CVE-2016-5386, aka https://httpoxy.org/ Fixes #16405 Change-Id: I6f68ade85421b4807785799f6d98a8b077e871f0 Reviewed-on: https://go-review.googlesource.com/25010 Run-TryBot: Chris Broadfoot <cbro@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Austin Clements authored
Most of the runtime improvements are hard to quantify or summarize, but it's worth mentioning some of the substantial improvements in STW time, and that the scavenger now actually works on ARM64, PPC64, and MIPS. Change-Id: I0e951038516378cc3f95b364716ef1c183f3445a Reviewed-on: https://go-review.googlesource.com/24966Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 17 Jul, 2016 1 commit
-
-
Brad Fitzpatrick authored
Only run TestDialerDualStack on the builders, as to not annoy or otherwise distract users when it's not their fault. Even though the intention is to only run this on the builders, very few of the builders have IPv6 support. Oh well. We'll get some coverage. Updates #13324 Change-Id: I13e7e3bca77ac990d290cabec88984cc3d24fb67 Reviewed-on: https://go-review.googlesource.com/24985 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
-
- 16 Jul, 2016 1 commit
-
-
Joe Tsai authored
Change https://golang.org/cl/19895 caused a regression where the last character in a string would be dropped if it was accompanied by an io.EOF. This change fixes the logic so that the last byte is still returned without a problem. Fixes #16393 Change-Id: I7a4d0abf761c2c15454136a79e065fe002d736ea Reviewed-on: https://go-review.googlesource.com/24981Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 15 Jul, 2016 1 commit
-
-
Ian Lance Taylor authored
We decided that ppc64 should maintain power5 compatibility. ppc64le requires power8. Fixes #16372. Change-Id: If5b309a0563f55a3c1fe9c853d29a463f5b71101 Reviewed-on: https://go-review.googlesource.com/24915Reviewed-by: Minux Ma <minux@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 14 Jul, 2016 1 commit
-
-
Josh Bleecher Snyder authored
Change-Id: I80ccf40cd3930aff908ee64f6dcbe5f5255198d3 Reviewed-on: https://go-review.googlesource.com/24914 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-