- 30 Jun, 2016 7 commits
-
-
Alan Donovan authored
+ test. Fixes #16230 Change-Id: Idac995437146a9df9e73f094d2a31abc25b1fa62 Reviewed-on: https://go-review.googlesource.com/24681Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
We had ~30 one way, and these four new occurrences the other way. Updates #11626 Change-Id: Ic6403dc4905874916ae292ff739d33482ed8e5bf Reviewed-on: https://go-review.googlesource.com/24683Reviewed-by:
Rob Pike <r@golang.org>
-
Alan Donovan authored
Fixes #16230 Change-Id: Ibb10234a6c3ab8bd0cfd93c2ebe8cfa66f80f6b0 Reviewed-on: https://go-review.googlesource.com/24682Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
Ctz is a hot-spot in the Go 1.7 memory manager. In SSA it's implemented as an intrinsic that compiles to a few instructions, but on the old backend (all architectures other than amd64), it's implemented as a fairly complex Go function. As a result, switching to bitmap-based allocation was a significant hit to allocation-heavy workloads like BinaryTree17 on non-SSA platforms. For unknown reasons, this hit 386 particularly hard. We can regain a lot of the lost performance by implementing Ctz in assembly on the 386. This isn't as good as an intrinsic, since it still generates a function call and prevents useful inlining, but it's much better than the pure Go implementation: name old time/op new time/op delta BinaryTree17-12 3.59s ± 1% 3.06s ± 1% -14.74% (p=0.000 n=19+20) Fannkuch11-12 3.72s ± 1% 3.64s ± 1% -2.09% (p=0.000 n=17+19) FmtFprintfEmpty-12 52.3ns ± 3% 52.3ns ± 3% ~ (p=0.829 n=20+19) FmtFprintfString-12 156ns ± 1% 148ns ± 3% -5.20% (p=0.000 n=18+19) FmtFprintfInt-12 137ns ± 1% 136ns ± 1% -0.56% (p=0.000 n=19+13) FmtFprintfIntInt-12 227ns ± 2% 225ns ± 2% -0.93% (p=0.000 n=19+17) FmtFprintfPrefixedInt-12 210ns ± 1% 208ns ± 1% -0.91% (p=0.000 n=19+17) FmtFprintfFloat-12 375ns ± 1% 371ns ± 1% -1.06% (p=0.000 n=19+18) FmtManyArgs-12 995ns ± 2% 978ns ± 1% -1.63% (p=0.000 n=17+17) GobDecode-12 9.33ms ± 1% 9.19ms ± 0% -1.59% (p=0.000 n=20+17) GobEncode-12 7.73ms ± 1% 7.73ms ± 1% ~ (p=0.771 n=19+20) Gzip-12 375ms ± 1% 374ms ± 1% ~ (p=0.141 n=20+18) Gunzip-12 61.8ms ± 1% 61.8ms ± 1% ~ (p=0.602 n=20+20) HTTPClientServer-12 87.7µs ± 2% 86.9µs ± 3% -0.87% (p=0.024 n=19+20) JSONEncode-12 20.2ms ± 1% 20.4ms ± 0% +0.53% (p=0.000 n=18+19) JSONDecode-12 65.3ms ± 0% 65.4ms ± 1% ~ (p=0.385 n=16+19) Mandelbrot200-12 4.11ms ± 1% 4.12ms ± 0% +0.29% (p=0.020 n=19+19) GoParse-12 3.75ms ± 1% 3.61ms ± 2% -3.90% (p=0.000 n=20+20) RegexpMatchEasy0_32-12 104ns ± 0% 103ns ± 0% -0.96% (p=0.000 n=13+16) RegexpMatchEasy0_1K-12 805ns ± 1% 803ns ± 1% ~ (p=0.189 n=18+18) RegexpMatchEasy1_32-12 111ns ± 0% 111ns ± 3% ~ (p=1.000 n=14+19) RegexpMatchEasy1_1K-12 1.00µs ± 1% 1.00µs ± 1% +0.50% (p=0.003 n=19+19) RegexpMatchMedium_32-12 133ns ± 2% 133ns ± 2% ~ (p=0.218 n=20+20) RegexpMatchMedium_1K-12 41.2µs ± 1% 42.2µs ± 1% +2.52% (p=0.000 n=18+16) RegexpMatchHard_32-12 2.35µs ± 1% 2.38µs ± 1% +1.53% (p=0.000 n=18+18) RegexpMatchHard_1K-12 70.9µs ± 2% 72.0µs ± 1% +1.42% (p=0.000 n=19+17) Revcomp-12 1.06s ± 0% 1.05s ± 0% -1.36% (p=0.000 n=20+18) Template-12 86.2ms ± 1% 84.6ms ± 0% -1.89% (p=0.000 n=20+18) TimeParse-12 425ns ± 2% 428ns ± 1% +0.77% (p=0.000 n=18+19) TimeFormat-12 517ns ± 1% 519ns ± 1% +0.43% (p=0.001 n=20+19) [Geo mean] 74.3µs 73.5µs -1.05% Prior to this commit, BinaryTree17-12 on 386 was 33% slower than at the go1.6 tag. With this commit, it's 13% slower. On arm and arm64, BinaryTree17-12 is only ~5% slower than it was at go1.6. It may be worth implementing Ctz for them as well. I consider this change low risk, since the functions it replaces are simple, very well specified, and well tested. For #16117. Change-Id: Ic39d851d5aca91330134596effd2dab9689ba066 Reviewed-on: https://go-review.googlesource.com/24640Reviewed-by:
Rick Hudson <rlh@golang.org> Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Previously we started checking for context cancelation in Wait, but that meant that when using StdoutPipe context cancelation never took effect. Fixes #16222. Change-Id: I89cd26d3499a6080bf1a07718ce38d825561899e Reviewed-on: https://go-review.googlesource.com/24650Reviewed-by:
-
Ian Lance Taylor authored
This should fix the report at #16224, and also fixes running the test as root on my Ubuntu Trusty system. Fixes #16224. Change-Id: I4e3b5527aa63366afb33a7e30efab088d34fb302 Reviewed-on: https://go-review.googlesource.com/24670 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev 8e573f40 for https://golang.org/cl/24600, "http2: merge multiple GOAWAY frames' contents into error message" Fixes #14627 (more) Change-Id: I5231607c2c9e0d854ad6199ded43c59e59f62f52 Reviewed-on: https://go-review.googlesource.com/24612 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Andrew Gerrand <adg@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 29 Jun, 2016 7 commits
-
-
Brad Fitzpatrick authored
There was only one use of "HTTP/1.n" compared to "HTTP/1.x": h2_bundle.go:// "Just as in HTTP/1.x, header field names are strings of ASCII httputil/dump.go:// DumpRequest returns the given request in its HTTP/1.x wire httputil/dump.go:// intact. HTTP/2 requests are dumped in HTTP/1.x form, not in their response.go:// Write writes r to w in the HTTP/1.x server response format, server.go: // Request.Body. For HTTP/1.x requests, handlers should read any server.go:// The default HTTP/1.x and HTTP/2 ResponseWriter implementations server.go:// The default ResponseWriter for HTTP/1.x connections supports server.go:// http1ServerSupportsRequest reports whether Go's HTTP/1.x server server.go: // about HTTP/1.x Handlers concurrently reading and writing, like server.go: // HTTP/1.x from here on. transport.go: return fmt.Errorf("net/http: HTTP/1.x transport connection broken: %v", err) Be consistent. Change-Id: I93c4c873e500f51af2b4762055e22f5487a625ac Reviewed-on: https://go-review.googlesource.com/24610Reviewed-by: -
Nick Harper authored
Change-Id: I2b7a81cb809d109f10d5f0db957c614f466d6bfd Reviewed-on: https://go-review.googlesource.com/24582Reviewed-by:
Adam Langley <agl@golang.org>
-
Tom Bergan authored
I believe it's necessary to use a buffer size smaller than 64KB because (at least some versions of) Window using a TCP receive window less than 64KB. Currently the client and server use buffer sizes of 16KB and 32KB, respectively (the server uses io.Copy, which defaults to 32KB internally). Since the server has been using 32KB, it should be safe for the client to do so as well. Fixes #15899 Change-Id: I36d44b29f2a5022c03fc086213d3c1adf153e983 Reviewed-on: https://go-review.googlesource.com/24581Reviewed-by:
-
Dmitry Vyukov authored
The assembly is broken: it does `MOVQ g(R12), R14` expecting that R12 contains tls address, but it does not do get_tls(R12) before. This magically works on linux: `MOVQ g(R12), R14` is compiled to `mov %fs:0xfffffffffffffff8,%r14` which does not use R12. But it crashes on windows. Add explicit `get_tls(R12)`. Fixes #16206 Change-Id: Ic1f21a6fef2473bcf9147de6646929781c9c1e98 Reviewed-on: https://go-review.googlesource.com/24590Reviewed-by:
-
Ian Lance Taylor authored
When the blocked field was first introduced back in https://golang.org/cl/61250043 the scheduler trace code incorrectly used m->blocked instead of mp->blocked. That has carried through the conversion to Go. This CL fixes it. Change-Id: Id81907b625221895aa5c85b9853f7c185efd8f4b Reviewed-on: https://go-review.googlesource.com/24571Reviewed-by:
-
Ian Lance Taylor authored
If creating a new thread fails with EAGAIN, point the user at ulimit. Fixes #15476. Change-Id: Ib36519614b5c72776ea7f218a0c62df1dd91a8ea Reviewed-on: https://go-review.googlesource.com/24570 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev ef2e00e88 for https://golang.org/cl/24560, "http2: make Transport return server's GOAWAY error back to the user" Fixes #14627 Change-Id: I2bb123a3041e168db7c9446beef4ee47638f17ee Reviewed-on: https://go-review.googlesource.com/24561Reviewed-by:
-
- 28 Jun, 2016 12 commits
-
-
Konstantin Shaposhnikov authored
Prior to this change package "foo" had to be installed in order to check example names in "foo_test" package. However by the time "foo_test" package is checked a parsed "foo" package has been already constructed. Use it to check example names. Also change TestDivergentPackagesExamples test to pass directory of the package to the vet tool as it is the most common way to invoke it. This requires changes to errchk to add support for grabbing source files from a directory. Fixes #16189 Change-Id: Ief103d07b024822282b86c24250835cc591793e8 Reviewed-on: https://go-review.googlesource.com/24488Reviewed-by:
-
Brad Fitzpatrick authored
TestPendingConnsAfterErr only cared that things didn't deadlock, so 5 seconds is a sufficient timer. We don't need 100 milliseconds. I was able to reproduce with a tiny (5 nanosecond) timeout value, instead of 100 milliseconds. In the process of testing with -race and a high -count= value, I noticed several data races and panics (sendings on a closed channel) which are also fixed in this change. Fixes #15684 Change-Id: Ib4605fcc0f296e658cb948352ed642b801cb578c Reviewed-on: https://go-review.googlesource.com/24550Reviewed-by:
Marko Tiikkaja <marko@joh.to> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Andrew Gerrand authored
Fixes #16165 Change-Id: Ic90e5873e0c8ee044f09543177192dcae1dcdbed Reviewed-on: https://go-review.googlesource.com/24531 Run-TryBot: Andrew Gerrand <adg@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Justyn Temme authored
Change-Id: I47bd98509663d75b0d4dedbdb778e803d90053cf Reviewed-on: https://go-review.googlesource.com/24216Reviewed-by:
-
Brad Fitzpatrick authored
Don't configure HTTP/2 in http.Server.Serve(net.Listener) if the Server's TLSConfig is set and doesn't include the "h2" NextProto value. This avoids mutating a *tls.Config already in use if previously passed to tls.NewListener. Also document this. (it's come up a few times now) Fixes #15908 Change-Id: I283eed82fdb29a791f80d801aadd9f75db244de0 Reviewed-on: https://go-review.googlesource.com/24508Reviewed-by:
-
Marcel van Lohuizen authored
Fixes #16201 Change-Id: I38c17859db78c2868905da24217e0ad47739c320 Reviewed-on: https://go-review.googlesource.com/24541 Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
Updates #16124 Change-Id: Ib58f2bb37fd1559efc512a2e3cba976f09b939a0 Reviewed-on: https://go-review.googlesource.com/24520Reviewed-by:
-
Marcel van Lohuizen authored
Changes beyond generated tables: - Now supports aliases to handle deprecated property classes. - Some Mongolian letters are now modifiers. Other changes: - strconv: newly generated table to be in sync - regexp/syntax: updated maxFold Fixes #16191 Change-Id: I56bdf21ee2f775f2a82d0465b3772faf5c24cb61 Reviewed-on: https://go-review.googlesource.com/24496 Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by:
-
David Crawshaw authored
Several minor changes that remove a good chunk of the overhead added to the reflect Name method over the 1.7 cycle, as seen from the non-SSA architectures. In particular, there are ~20 fewer instructions in reflect.name.name on 386, and the method now qualifies for inlining. The simple JSON decoding benchmark on darwin/386: name old time/op new time/op delta CodeDecoder-8 49.2ms ± 0% 48.9ms ± 1% -0.77% (p=0.000 n=10+9) name old speed new speed delta CodeDecoder-8 39.4MB/s ± 0% 39.7MB/s ± 1% +0.77% (p=0.000 n=10+9) On darwin/amd64 the effect is less pronounced: name old time/op new time/op delta CodeDecoder-8 38.9ms ± 0% 38.7ms ± 1% -0.38% (p=0.005 n=10+10) name old speed new speed delta CodeDecoder-8 49.9MB/s ± 0% 50.1MB/s ± 1% +0.38% (p=0.006 n=10+10) Counterintuitively, I get much more useful benchmark data out of my MacBook Pro than a linux workstation with more expensive Intel chips. While the laptop has fewer cores and an active GUI, the single-threaded performance is significantly better (nearly 1.5x decoding throughput) so the differences are more pronounced. For #16117. Change-Id: I4e0cc1cc2d271d47d5127b1ee1ca926faf34cabf Reviewed-on: https://go-review.googlesource.com/24510Reviewed-by:
-
Lynn Boger authored
This modifies a recent performance improvement to the And8 and Or8 atomic functions which required both ppc64le and ppc64 to use power8 instructions. Since then it was decided that ppc64 (BE) should work for power5 and later. This change uses instructions compatible with power5 for ppc64 and uses power8 for ppc64le. Fixes #16004 Change-Id: I623c75e8e6fd1fa063a53d250d86cdc9d0890dc7 Reviewed-on: https://go-review.googlesource.com/24181Reviewed-by:
-
Raul Silvera authored
The version of pprof in gperftools has been deprecated. No need to have a pointer to that version since go tool pprof is included with the Go distro. Change-Id: I6d769a68f64280f5db89ff6fbc67bfea9c8f1526 Reviewed-on: https://go-review.googlesource.com/24509Reviewed-by:
-
David Crawshaw authored
On linux/386 compared to tip: name old time/op new time/op delta DecodeInterfaceSlice-40 1.23ms ± 1% 1.17ms ± 1% -4.93% (p=0.000 n=9+10) Recovers about half the performance regression from Go 1.6 on 386. For #16117. Change-Id: Ie8676d92a4da3e27ff21b91a98b3e13d16730ba1 Reviewed-on: https://go-review.googlesource.com/24468Reviewed-by:
-
- 27 Jun, 2016 10 commits
-
-
Dmitri Popov authored
Do not throw away the rest of Int63 value used for generation random bytes. Save it in Rand struct and re-use during the next Read call. Fixes #16124 Change-Id: Ic70bd80c3c3a6590e60ac615e8b3c2324589bea3 Reviewed-on: https://go-review.googlesource.com/24251Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Vladimir Mihailenco authored
Fixes #16162. Change-Id: I6f4ae906630079ef5fc29ee5f70e2e3d1c962170 Reviewed-on: https://go-review.googlesource.com/24390Reviewed-by:
-
Ian Lance Taylor authored
This fixes some 40 warnings from go vet. Fixes #16134. Change-Id: Ib9fcba275fe692f027a2a07b581c8cf503b11087 Reviewed-on: https://go-review.googlesource.com/24287Reviewed-by:
-
Konstantin Shaposhnikov authored
Change ExampleResponseRecorder to use httptest.NewRequest instead of http.NewRequest. This makes the example shorter and shows how to use one more function from the httptest package. Change-Id: I3d35869bd0a4daf1c7551b649428bb2f2a45eba2 Reviewed-on: https://go-review.googlesource.com/24480 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Fixes #16197 Change-Id: Icaabacbb22bc18c52b9e04b47385ac5325fcccd1 Reviewed-on: https://go-review.googlesource.com/24505 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
The compiler was treating all global function literals as occurring in a function named "glob", which caused a symbol name collision when there was an actual function named "glob". Fixed by adding a period. Fixes #16193. Change-Id: I67792901a8ca04635ba41d172bfaee99944f594d Reviewed-on: https://go-review.googlesource.com/24500Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Raul Silvera authored
In the comments for this file there is a reference to gperftools for more info on pprof. pprof now live on its own repo on github, and the version in gperftools is deprecated. Change-Id: I8a188f129534f73edd132ef4e5a2d566e69df7e9 Reviewed-on: https://go-review.googlesource.com/24502Reviewed-by:
-
Keith Randall authored
Make sure the pointer to the heap copy of an output parameter is kept live throughout the function. The function could panic at any point, and then a defer could recover. Thus, we need the pointer to the heap copy always available so the post-deferreturn code can copy the return value back to the stack. Before this CL, the pointer to the heap copy could be considered dead in certain situations, like code which is reverse dominated by a panic call. Fixes #16095. Change-Id: Ic3800423e563670e5b567b473bf4c84cddb49a4c Reviewed-on: https://go-review.googlesource.com/24213 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Konstantin Shaposhnikov authored
This fixes the obvious bug and makes go vet look for identifiers in foo package when checking example names in foo_test package. Note that for this check to work the foo package have to be installed (using go install). This commit however doesn't fix TestDivergentPackagesExamples test that is not implemented correctly and passes only by chance. Updates #16189 Change-Id: I5c2f675cd07e5b66cf0432b2b3e422ab45c3dedd Reviewed-on: https://go-review.googlesource.com/24487Reviewed-by:
Dmitri Shuralyov <shurcool@gmail.com> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Crawshaw authored
Swtich from a sync.RWMutex to atomic.Value for cacheTypeFields. On GOARCH=386, this recovers most of the remaining performance difference from the 1.6 release. Compared with tip on linux/386: name old time/op new time/op delta CodeDecoder-40 92.8ms ± 1% 87.7ms ± 1% -5.50% (p=0.000 n=10+10) name old speed new speed delta CodeDecoder-40 20.9MB/s ± 1% 22.1MB/s ± 1% +5.83% (p=0.000 n=10+10) With more time and care, I believe more of the JSON decoder's work could be shifted so it is done before decoding, and independent of the number of bytes processed. Maybe someone could explore that for Go 1.8. For #16117. Change-Id: I049655b2e5b76384a0d5f4b90e3ec7cc8d8c4340 Reviewed-on: https://go-review.googlesource.com/24472 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 26 Jun, 2016 1 commit
-
-
Konstantin Shaposhnikov authored
Fixes #15788 Change-Id: I5a1fd1e5992f1c16cf8d8437d742bf02e1653b9c Reviewed-on: https://go-review.googlesource.com/23461Reviewed-by:
-
- 25 Jun, 2016 1 commit
-
-
Ian Lance Taylor authored
If we are using a remote source (a URL), and the user did not specify the executable file to use, then don't try to use a local source. This was misbehaving because the local symbolizer will not fail if there is any memory map available, but the presence of a memory map does not ensure that the files and symbols are actually available. We still need a pprof testsuite. Fixes #16159. Change-Id: I0250082a4d5181c7babc7eeec6bc95b2f3bcaec9 Reviewed-on: https://go-review.googlesource.com/24464 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
- 24 Jun, 2016 2 commits
-
-
Ian Lance Taylor authored
Handling a symbol with address 0 and size 0, such as an ELF STT_FILE symbols, was causing us to disassemble the entire program. We started adding STT_FILE symbols to help fix issue #13247. Fixes #16154. Change-Id: I174b9614e66ddc3d65801f7c1af7650f291ac2af Reviewed-on: https://go-review.googlesource.com/24460 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Nathan VanBenschoten authored
Previously, a 0 mantissa was special-cased during big.Float parsing, but not during big.Rat parsing. This meant that a value like 0e9999999999 would parse successfully in big.Float.SetString, but would hang in big.Rat.SetString. This discrepancy became an issue in https://golang.org/src/go/constant/value.go?#L250, where the big.Float would report an exponent of 0, so big.Rat.SetString would be used and would subsequently hang. A Go Playground example of this is https://play.golang.org/p/3fy28eUJuF The solution is to special-case a zero mantissa during big.Rat parsing as well, so that neither big.Rat nor big.Float will hang when parsing a value with 0 mantissa but a large exponent. This was discovered using go-fuzz on CockroachDB: https://github.com/cockroachdb/go-fuzz/blob/master/examples/parser/main.go Fixes #16176 Change-Id: I775558a8682adbeba1cc9d20ba10f8ed26259c56 Reviewed-on: https://go-review.googlesource.com/24430Reviewed-by:
-
