- 24 Sep, 2018 10 commits
-
-
Keith Randall authored
Document what the fields of regalloc mean. Hopefully will help people understand how the register allocator works. Change-Id: Ic322ed2019cc839b812740afe8cd2cf0b61da046 Reviewed-on: https://go-review.googlesource.com/137016Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Katie Hockman authored
The previous book was 387 KiB decompressed and 119 KiB compressed, the new book is 567 KiB decompressed and 132 KiB compressed. Overall, this change will reduce the release binary size by 196 KiB. The new book will allow for slightly more extensive compression testing with a larger text. Command to run the benchmark tests used with benchstat: `../bin/go test -run='^$' -count=4 -bench=. compress/bzip2 compress/flate` When running the benchmarks locally, changed "Newton" to "Twain" and filtered the tests with the -bench flag to include only those which were relevant to these changes. benchstat results below: name old time/op new time/op delta DecodeTwain-8 19.6ms ± 2% 24.1ms ± 1% +23.04% (p=0.029 n=4+4) Decode/Twain/Huffman/1e4-8 140µs ± 3% 139µs ± 5% ~ (p=0.886 n=4+4) Decode/Twain/Huffman/1e5-8 1.27ms ± 3% 1.26ms ± 1% ~ (p=1.000 n=4+4) Decode/Twain/Huffman/1e6-8 12.4ms ± 0% 13.2ms ± 1% +6.42% (p=0.029 n=4+4) Decode/Twain/Speed/1e4-8 133µs ± 1% 123µs ± 1% -7.35% (p=0.029 n=4+4) Decode/Twain/Speed/1e5-8 1.20ms ± 0% 1.02ms ± 3% -15.32% (p=0.029 n=4+4) Decode/Twain/Speed/1e6-8 12.0ms ± 2% 10.1ms ± 3% -15.89% (p=0.029 n=4+4) Decode/Twain/Default/1e4-8 131µs ± 6% 108µs ± 5% -17.84% (p=0.029 n=4+4) Decode/Twain/Default/1e5-8 1.06ms ± 2% 0.80ms ± 1% -24.97% (p=0.029 n=4+4) Decode/Twain/Default/1e6-8 10.0ms ± 3% 8.0ms ± 3% -20.06% (p=0.029 n=4+4) Decode/Twain/Compression/1e4-8 128µs ± 4% 115µs ± 4% -9.70% (p=0.029 n=4+4) Decode/Twain/Compression/1e5-8 1.04ms ± 2% 0.83ms ± 4% -20.37% (p=0.029 n=4+4) Decode/Twain/Compression/1e6-8 10.4ms ± 4% 8.1ms ± 5% -22.25% (p=0.029 n=4+4) Encode/Twain/Huffman/1e4-8 55.7µs ± 2% 55.6µs ± 1% ~ (p=1.000 n=4+4) Encode/Twain/Huffman/1e5-8 441µs ± 0% 435µs ± 2% ~ (p=0.343 n=4+4) Encode/Twain/Huffman/1e6-8 4.31ms ± 4% 4.30ms ± 4% ~ (p=0.886 n=4+4) Encode/Twain/Speed/1e4-8 193µs ± 1% 166µs ± 2% -14.09% (p=0.029 n=4+4) Encode/Twain/Speed/1e5-8 1.54ms ± 1% 1.22ms ± 1% -20.53% (p=0.029 n=4+4) Encode/Twain/Speed/1e6-8 15.3ms ± 1% 12.2ms ± 3% -20.62% (p=0.029 n=4+4) Encode/Twain/Default/1e4-8 393µs ± 1% 390µs ± 1% ~ (p=0.114 n=4+4) Encode/Twain/Default/1e5-8 6.12ms ± 4% 6.02ms ± 5% ~ (p=0.486 n=4+4) Encode/Twain/Default/1e6-8 69.4ms ± 5% 59.0ms ± 4% -15.07% (p=0.029 n=4+4) Encode/Twain/Compression/1e4-8 423µs ± 2% 379µs ± 2% -10.34% (p=0.029 n=4+4) Encode/Twain/Compression/1e5-8 7.00ms ± 1% 7.88ms ± 3% +12.49% (p=0.029 n=4+4) Encode/Twain/Compression/1e6-8 76.6ms ± 5% 80.9ms ± 3% ~ (p=0.114 n=4+4) name old speed new speed delta DecodeTwain-8 19.8MB/s ± 2% 23.6MB/s ± 1% +18.84% (p=0.029 n=4+4) Decode/Twain/Huffman/1e4-8 71.7MB/s ± 3% 72.1MB/s ± 6% ~ (p=0.943 n=4+4) Decode/Twain/Huffman/1e5-8 78.8MB/s ± 3% 79.5MB/s ± 1% ~ (p=1.000 n=4+4) Decode/Twain/Huffman/1e6-8 80.5MB/s ± 0% 75.6MB/s ± 1% -6.03% (p=0.029 n=4+4) Decode/Twain/Speed/1e4-8 75.2MB/s ± 1% 81.2MB/s ± 1% +7.93% (p=0.029 n=4+4) Decode/Twain/Speed/1e5-8 83.4MB/s ± 0% 98.6MB/s ± 3% +18.16% (p=0.029 n=4+4) Decode/Twain/Speed/1e6-8 83.6MB/s ± 2% 99.5MB/s ± 3% +18.91% (p=0.029 n=4+4) Decode/Twain/Default/1e4-8 76.3MB/s ± 6% 92.8MB/s ± 4% +21.62% (p=0.029 n=4+4) Decode/Twain/Default/1e5-8 94.4MB/s ± 3% 125.7MB/s ± 1% +33.24% (p=0.029 n=4+4) Decode/Twain/Default/1e6-8 100MB/s ± 3% 125MB/s ± 3% +25.12% (p=0.029 n=4+4) Decode/Twain/Compression/1e4-8 78.4MB/s ± 4% 86.8MB/s ± 4% +10.73% (p=0.029 n=4+4) Decode/Twain/Compression/1e5-8 95.7MB/s ± 2% 120.3MB/s ± 4% +25.65% (p=0.029 n=4+4) Decode/Twain/Compression/1e6-8 96.4MB/s ± 4% 124.0MB/s ± 5% +28.64% (p=0.029 n=4+4) Encode/Twain/Huffman/1e4-8 179MB/s ± 2% 180MB/s ± 1% ~ (p=1.000 n=4+4) Encode/Twain/Huffman/1e5-8 227MB/s ± 0% 230MB/s ± 2% ~ (p=0.343 n=4+4) Encode/Twain/Huffman/1e6-8 232MB/s ± 4% 233MB/s ± 4% ~ (p=0.886 n=4+4) Encode/Twain/Speed/1e4-8 51.8MB/s ± 1% 60.4MB/s ± 2% +16.43% (p=0.029 n=4+4) Encode/Twain/Speed/1e5-8 65.1MB/s ± 1% 81.9MB/s ± 1% +25.83% (p=0.029 n=4+4) Encode/Twain/Speed/1e6-8 65.2MB/s ± 1% 82.2MB/s ± 3% +26.00% (p=0.029 n=4+4) Encode/Twain/Default/1e4-8 25.4MB/s ± 1% 25.6MB/s ± 1% ~ (p=0.114 n=4+4) Encode/Twain/Default/1e5-8 16.4MB/s ± 4% 16.6MB/s ± 5% ~ (p=0.486 n=4+4) Encode/Twain/Default/1e6-8 14.4MB/s ± 6% 17.0MB/s ± 4% +17.67% (p=0.029 n=4+4) Encode/Twain/Compression/1e4-8 23.6MB/s ± 2% 26.4MB/s ± 2% +11.54% (p=0.029 n=4+4) Encode/Twain/Compression/1e5-8 14.3MB/s ± 1% 12.7MB/s ± 3% -11.08% (p=0.029 n=4+4) Encode/Twain/Compression/1e6-8 13.1MB/s ± 4% 12.4MB/s ± 3% ~ (p=0.114 n=4+4) name old alloc/op new alloc/op delta DecodeTwain-8 3.63MB ± 0% 3.63MB ± 0% +0.15% (p=0.029 n=4+4) Decode/Twain/Huffman/1e4-8 42.0kB ± 0% 41.3kB ± 0% -1.62% (p=0.029 n=4+4) Decode/Twain/Huffman/1e5-8 43.5kB ± 0% 45.1kB ± 0% +3.74% (p=0.029 n=4+4) Decode/Twain/Huffman/1e6-8 71.7kB ± 0% 80.0kB ± 0% +11.55% (p=0.029 n=4+4) Decode/Twain/Speed/1e4-8 41.2kB ± 0% 41.3kB ± 0% ~ (p=0.286 n=4+4) Decode/Twain/Speed/1e5-8 45.1kB ± 0% 43.9kB ± 0% -2.80% (p=0.029 n=4+4) Decode/Twain/Speed/1e6-8 72.8kB ± 0% 81.3kB ± 0% +11.72% (p=0.029 n=4+4) Decode/Twain/Default/1e4-8 41.2kB ± 0% 41.2kB ± 0% -0.22% (p=0.029 n=4+4) Decode/Twain/Default/1e5-8 44.4kB ± 0% 43.0kB ± 0% -3.02% (p=0.029 n=4+4) Decode/Twain/Default/1e6-8 71.0kB ± 0% 61.8kB ± 0% -13.00% (p=0.029 n=4+4) Decode/Twain/Compression/1e4-8 41.3kB ± 0% 41.2kB ± 0% -0.29% (p=0.029 n=4+4) Decode/Twain/Compression/1e5-8 43.3kB ± 0% 43.0kB ± 0% -0.72% (p=0.029 n=4+4) Decode/Twain/Compression/1e6-8 69.1kB ± 0% 63.7kB ± 0% -7.90% (p=0.029 n=4+4) name old allocs/op new allocs/op delta DecodeTwain-8 51.0 ± 0% 51.2 ± 1% ~ (p=1.000 n=4+4) Decode/Twain/Huffman/1e4-8 15.0 ± 0% 14.0 ± 0% -6.67% (p=0.029 n=4+4) Decode/Twain/Huffman/1e5-8 20.0 ± 0% 23.0 ± 0% +15.00% (p=0.029 n=4+4) Decode/Twain/Huffman/1e6-8 134 ± 0% 161 ± 0% +20.15% (p=0.029 n=4+4) Decode/Twain/Speed/1e4-8 17.0 ± 0% 18.0 ± 0% +5.88% (p=0.029 n=4+4) Decode/Twain/Speed/1e5-8 30.0 ± 0% 31.0 ± 0% +3.33% (p=0.029 n=4+4) Decode/Twain/Speed/1e6-8 193 ± 0% 228 ± 0% +18.13% (p=0.029 n=4+4) Decode/Twain/Default/1e4-8 17.0 ± 0% 15.0 ± 0% -11.76% (p=0.029 n=4+4) Decode/Twain/Default/1e5-8 28.0 ± 0% 32.0 ± 0% +14.29% (p=0.029 n=4+4) Decode/Twain/Default/1e6-8 199 ± 0% 158 ± 0% -20.60% (p=0.029 n=4+4) Decode/Twain/Compression/1e4-8 17.0 ± 0% 15.0 ± 0% -11.76% (p=0.029 n=4+4) Decode/Twain/Compression/1e5-8 28.0 ± 0% 32.0 ± 0% +14.29% (p=0.029 n=4+4) Decode/Twain/Compression/1e6-8 196 ± 0% 150 ± 0% -23.47% (p=0.029 n=4+4) Updates #27151 Change-Id: I6c439694ed16a33bb4c63fbfb8570c7de46b4f2d Reviewed-on: https://go-review.googlesource.com/135495Reviewed-by:
Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
Brad Fitzpatrick authored
From https://github.com/golang/go/issues/17659#issuecomment-423113606 ... > In kubernetes , isDomainName reject Pods "A Record" "pod-ip-address", > for example: "172-17-0-16", as RFC 3696 section 2 requires > "top-level domain names not be all-numeric", but this example has > three hyphen, so I think it should not be reject. Updates #17659 Change-Id: Ibd8ffb9473d69c45c91525953c09c6749233ca20 Reviewed-on: https://go-review.googlesource.com/136900 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Ian Gudger <igudger@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Davis authored
Added in preparation for looking at some optimizations around bounds checks. BenchmarkAt/rgba-8 100000000 18.5 ns/op 4 B/op 1 allocs/op BenchmarkAt/rgba64-8 100000000 22.9 ns/op 8 B/op 1 allocs/op BenchmarkAt/nrgba-8 100000000 18.8 ns/op 4 B/op 1 allocs/op BenchmarkAt/nrgba64-8 100000000 22.1 ns/op 8 B/op 1 allocs/op BenchmarkAt/alpha-8 100000000 14.6 ns/op 1 B/op 1 allocs/op BenchmarkAt/alpha16-8 200000000 6.46 ns/op 0 B/op 0 allocs/op BenchmarkAt/gray-8 100000000 14.3 ns/op 1 B/op 1 allocs/op BenchmarkAt/gray16-8 200000000 6.45 ns/op 0 B/op 0 allocs/op BenchmarkAt/paletted-8 300000000 4.28 ns/op 0 B/op 0 allocs/op BenchmarkSet/rgba-8 50000000 39.2 ns/op 8 B/op 2 allocs/op BenchmarkSet/rgba64-8 30000000 45.8 ns/op 16 B/op 2 allocs/op BenchmarkSet/nrgba-8 50000000 39.3 ns/op 8 B/op 2 allocs/op BenchmarkSet/nrgba64-8 30000000 45.6 ns/op 16 B/op 2 allocs/op BenchmarkSet/alpha-8 50000000 34.5 ns/op 2 B/op 2 allocs/op BenchmarkSet/alpha16-8 50000000 34.9 ns/op 4 B/op 2 allocs/op BenchmarkSet/gray-8 100000000 20.3 ns/op 1 B/op 1 allocs/op BenchmarkSet/gray16-8 50000000 36.2 ns/op 4 B/op 2 allocs/op BenchmarkSet/paletted-8 50000000 39.5 ns/op 1 B/op 1 allocs/op BenchmarkRGBAAt-8 500000000 3.74 ns/op BenchmarkRGBASetRGBA-8 300000000 4.33 ns/op BenchmarkRGBA64At-8 300000000 5.06 ns/op BenchmarkRGBA64SetRGBA64-8 200000000 6.61 ns/op BenchmarkNRGBAAt-8 500000000 3.69 ns/op BenchmarkNRGBASetNRGBA-8 300000000 4.06 ns/op BenchmarkNRGBA64At-8 300000000 4.98 ns/op BenchmarkNRGBA64SetNRGBA64-8 200000000 6.62 ns/op BenchmarkAlphaAt-8 2000000000 1.43 ns/op BenchmarkAlphaSetAlpha-8 2000000000 1.55 ns/op BenchmarkAlpha16At-8 1000000000 2.87 ns/op BenchmarkAlphaSetAlpha16-8 500000000 3.27 ns/op BenchmarkGrayAt-8 2000000000 1.43 ns/op BenchmarkGraySetGray-8 2000000000 1.55 ns/op BenchmarkGray16At-8 1000000000 2.87 ns/op BenchmarkGraySetGray16-8 500000000 3.14 ns/op Updates #14884 Change-Id: I349fb214ee75f13ecbc62ac22a40e3b337648f60 Reviewed-on: https://go-review.googlesource.com/136796Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
&^ and << have equal precedence. Add some parentheses to make sure we shift before we andnot. Fixes #27829 Change-Id: Iba8576201f0f7c52bf9795aaa75d15d8f9a76811 Reviewed-on: https://go-review.googlesource.com/136899Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Andrei Tudor Călin authored
As pointed out in the aftermath of CL 113997, splice is not supported for SOCK_SEQPACKET or SOCK_DGRAM unix sockets. Don't call poll.Splice in those cases. Change-Id: Ieab18fb0ae706fdeb249e3f54d51a3292e3ead62 Reviewed-on: https://go-review.googlesource.com/136635 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Jongmin Kim authored
The existing URL in comment points to an Alioth page which was deprecated (and not working), so use the new Benchmarks Game URL. Change-Id: Ifd694382a44a24c44acbed3fe1b17bca6dab998f Reviewed-on: https://go-review.googlesource.com/136835Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Elias Naur authored
Implement Lstat with fstatat and Lchown with Fchownat on linux/amd64, linux/arm and linux/386. Furthermore, implement Stat with fstatat on linux/arm and linux/386. Linux/arm64 already had similar replacements. The fstatat and fchownat system calls were added in kernel 2.6.16, which is before the Go minimum, 2.6.23. The three syscalls then match the android bionic implementation and avoids the Android O seccomp filter. Fixes #27797 Change-Id: I07fd5506955d454a1a660fef5af0e1ac1ecb0959 Reviewed-on: https://go-review.googlesource.com/136795 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
The noopt builder is configured by setting GO_GCFLAGS=-N -l, but the test/run.go test harness doesn't look at GO_GCFLAGS when processing "errorcheck" files, it just calls compile: cmdline := []string{goTool(), "tool", "compile", /* etc */} This is working as intended, since it makes the tests more robust and independent from the environment; errorcheck files are supposed to set additional building flags, when needed, like in: // errorcheck -0 -N -l The test/bcecheck.go test used to work on the noopt builder (even if bce is not active on -N -l) because the test was auto-contained and the file always compiled with optimizations enabled. In CL 107355, a new bce test dependent on an external package (encoding.binary) was added. On the noopt builder the external package is built using -N -l, and this causes a test failure that broke the noopt builder: https://build.golang.org/log/b2be319536285e5807ee9d66d6d0ec4d57433768 To reproduce the failure, one can do: $ go install -a -gcflags="-N -l" std $ go run run.go -- checkbce.go This change fixes the noopt builder breakage by removing the bce test dependency on encoding/binary by defining a local Uint64() function to be used in the test. Change-Id: Ife71aab662001442e715c32a0b7d758349a63ff1 Reviewed-on: https://go-review.googlesource.com/136855Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Eugene Kalinin authored
Previously consumeValue performed consumption of "unnecessary backslashes" strictly for non-ASCII and non-token runes. Thus if it encountered a backslash before a rune that is out of the ASCII range, it would erroneously skip that backslash. This change now derestricts "unnecessary backslash" unescaping for all character encodings, using "isTSpecial" instead of "!isTokenChar". This change is a follow-up of CL 32175. Fixes #25888 Change-Id: I5e02bbf9c42f753a6eb31399b8d20315af991490 Reviewed-on: https://go-review.googlesource.com/119795Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 23 Sep, 2018 2 commits
-
-
Johan Brandhorst authored
The Fetch API returns a null body if there is no response body, on browsers that support streaming the response body. This change ensures we check for both undefined and null bodies before attempting to read the body. Fixes #27196 Change-Id: I0da86b61284fe394418b4b431495e715a037f335 Reviewed-on: https://go-review.googlesource.com/131236Reviewed-by:
Richard Musiol <neelance@gmail.com> Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Vladimir Varankin authored
cloneHeader duplicates what Header.clone() method is doing. It's used in a single place, which can be replaced with the use of the method. Change-Id: I6e8bbd6c95063f31ca3695f13fa7478873230525 GitHub-Last-Rev: eb08aeae9b4257df5cf08d6d30903ddeec6b6242 GitHub-Pull-Request: golang/go#27817 Reviewed-on: https://go-review.googlesource.com/136762Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 20 Sep, 2018 8 commits
-
-
Robert Griesemer authored
Node.copy used to make a shallow copy of a node. Often, this is not correct: If a node n's Orig field pointed to itself, the copy's Orig field has to be adjusted to point to the copy. Otherwise, if n is modified later, the copy's Orig appears modified as well (because it points to n). This was fixed for one specific case with https://go-review.googlesource.com/c/go/+/136395 (issue #26855). This change instead addresses copy in general: In two cases we don't want the Orig adjustment as it causes escape analysis output to fail (not match the existing error messages). rawcopy is used in those cases. In several cases Orig is set to the copy immediately after making a copy; a new function sepcopy is used there. Updates #26855. Fixes #27765. Change-Id: Idaadeb5c4b9a027daabd46a2361348f7a93f2b00 Reviewed-on: https://go-review.googlesource.com/136540Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Iskander Sharipov authored
Move slice self-assign check into isSelfAssign function. Make debug output consistent for all self-assignment cases. Change-Id: I0e4cc7b3c1fcaeace7226dd80a0dc1ea97347a55 Reviewed-on: https://go-review.googlesource.com/136276 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Ben Shi authored
The ADDconstmodify has similar logic with other constmodify like instructions. This CL optimize them to share code via fallthrough. And the size of pkg/linux_386/cmd/compile/internal/x86.a decreases about 0.3KB. Change-Id: Ibdf06228afde875e8fe8e30851b50ca2be513dd9 Reviewed-on: https://go-review.googlesource.com/136398 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Robert Griesemer authored
Found while tracking down #26855. Change-Id: Ice137fe390820ba351e1c7439b6a9a1b3bdc966b Reviewed-on: https://go-review.googlesource.com/136396 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
See the change and comment in typecheck.go for a detailed explanation. Fixes #26855. Change-Id: I7867f948490fc0873b1bd849048cda6acbc36e76 Reviewed-on: https://go-review.googlesource.com/136395Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Use String and GoString methods instead of the xconf names for the numeric conversion routines. Also, fixed a couple of comments in fmt.go. Change-Id: I1b8acdd95dbff3fc30273070fbb1ac4860031a3c Reviewed-on: https://go-review.googlesource.com/136197Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I863eb8ef491e1d51b83d8dd3061bf11cbdc74a3e Reviewed-on: https://go-review.googlesource.com/136196Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
The fconv flag arguments were 0, FmtSharp, and FmtSharp|FmtSign. The 0 value was used for binary representation only, which was readily available via Mpflt.String. Otherwise, FmtSharp was always passed. FmtSign was used to print the '+' sign in case of a positive number and only needed for complex number formatting. Instead implemented cconv and handled it there. Change-Id: I1f77282f995be9cfda05efb71a0e027836a9da26 Reviewed-on: https://go-review.googlesource.com/136195Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
- 19 Sep, 2018 9 commits
-
-
Joe Tsai authored
The current usage of sync.Pool is leaky because it stores an arbitrary sized buffer into the pool. However, sync.Pool assumes that all items in the pool are interchangeable from a memory cost perspective. Due to the unbounded size of a buffer that may be added, it is possible for the pool to eventually pin arbitrarily large amounts of memory in a live-lock situation. As a simple fix, we just set a maximum size that we permit back into the pool. We do not need to fix the use of a sync.Pool in scan.go since the free method has always enforced a maximum capacity since the first commit of the scan logic. Fixes #27740 Updates #23199 Change-Id: I875278f7dba42625405df36df3e9b028252ce5e3 Reviewed-on: https://go-review.googlesource.com/136116Reviewed-by:
Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Some variants of Mercurial respond differently to “permission denied” errors than to “file not found”, and we set HOME to point to an absolute path that may produce the former instead of the latter. To discourage Mercurial from trying HOME, give it an explicit (empty) configuration in the working directory instead. Change-Id: I82ae99a6892bba7fc3d41b77209ca181d24315e2 Reviewed-on: https://go-review.googlesource.com/136135Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tim Xu authored
Clean mod cache should print remove commands and not run them when with set "-n" option. Fixes #27458. Change-Id: I97242cb40c062b347784cdb61653c84a3a7eab44 GitHub-Last-Rev: 5a6f10cad8c5f2c3916a74ca5eea27b1fdd1dc38 GitHub-Pull-Request: golang/go#27710 Reviewed-on: https://go-review.googlesource.com/135695 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Iskander Sharipov authored
Since there are no nested loops and/or switches, loop label can be removed and "bare continue" can be used. Change-Id: Id642a0859299e4470af544d59884fec51dbb31ee Reviewed-on: https://go-review.googlesource.com/135837Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Iskander Sharipov authored
Teach samesafeexpr to handle arithmetic unary and binary ops. It makes map lookup optimization possible in m[k+1] = append(m[k+1], ...) m[-k] = append(m[-k], ...) ... etc Does not cover "+" for strings (concatenation). Change-Id: Ibbb16ac3faf176958da344be1471b06d7cf33a6c Reviewed-on: https://go-review.googlesource.com/135795 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Iskander Sharipov authored
Change-Id: I4ee4f702e1bfc9ad9ea899c255104d5e18cf2c96 Reviewed-on: https://go-review.googlesource.com/135838Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ben Shi authored
Currently "arr[idx] |= 0x80" is compiled to MOVLload->BTSL->MOVLstore. And this CL optimizes it to a single BTSLconstmodify. Other bit wise operations with a direct memory operand are also implemented. 1. The size of the executable bin/go decreases about 4KB, and the total size of pkg/linux_amd64 (excluding cmd/compile) decreases about 0.6KB. 2. There a little improvement in the go1 benchmark test (excluding noise). name old time/op new time/op delta BinaryTree17-4 2.66s ± 4% 2.66s ± 3% ~ (p=0.596 n=49+49) Fannkuch11-4 2.38s ± 2% 2.32s ± 2% -2.69% (p=0.000 n=50+50) FmtFprintfEmpty-4 42.7ns ± 4% 43.2ns ± 7% +1.31% (p=0.009 n=50+50) FmtFprintfString-4 71.0ns ± 5% 72.0ns ± 3% +1.33% (p=0.000 n=50+50) FmtFprintfInt-4 80.7ns ± 4% 80.6ns ± 3% ~ (p=0.931 n=50+50) FmtFprintfIntInt-4 125ns ± 3% 126ns ± 4% ~ (p=0.051 n=50+50) FmtFprintfPrefixedInt-4 158ns ± 1% 142ns ± 3% -9.84% (p=0.000 n=36+50) FmtFprintfFloat-4 215ns ± 4% 212ns ± 4% -1.23% (p=0.002 n=50+50) FmtManyArgs-4 519ns ± 3% 510ns ± 3% -1.77% (p=0.000 n=50+50) GobDecode-4 6.49ms ± 6% 6.52ms ± 5% ~ (p=0.866 n=50+50) GobEncode-4 5.93ms ± 8% 6.01ms ± 7% ~ (p=0.076 n=50+50) Gzip-4 222ms ± 4% 224ms ± 8% +0.80% (p=0.001 n=50+50) Gunzip-4 36.6ms ± 5% 36.4ms ± 4% ~ (p=0.093 n=50+50) HTTPClientServer-4 59.1µs ± 1% 58.9µs ± 2% -0.24% (p=0.039 n=49+48) JSONEncode-4 9.23ms ± 4% 9.21ms ± 5% ~ (p=0.244 n=50+50) JSONDecode-4 48.8ms ± 4% 48.7ms ± 4% ~ (p=0.653 n=50+50) Mandelbrot200-4 3.81ms ± 4% 3.80ms ± 3% ~ (p=0.834 n=50+50) GoParse-4 3.20ms ± 5% 3.19ms ± 5% ~ (p=0.494 n=50+50) RegexpMatchEasy0_32-4 78.1ns ± 2% 77.4ns ± 3% -0.86% (p=0.005 n=50+50) RegexpMatchEasy0_1K-4 233ns ± 3% 233ns ± 3% ~ (p=0.074 n=50+50) RegexpMatchEasy1_32-4 74.2ns ± 3% 73.4ns ± 3% -1.06% (p=0.000 n=50+50) RegexpMatchEasy1_1K-4 369ns ± 2% 364ns ± 4% -1.41% (p=0.000 n=36+50) RegexpMatchMedium_32-4 109ns ± 4% 107ns ± 3% -2.06% (p=0.001 n=50+50) RegexpMatchMedium_1K-4 31.5µs ± 3% 30.8µs ± 3% -2.20% (p=0.000 n=50+50) RegexpMatchHard_32-4 1.57µs ± 3% 1.56µs ± 2% -0.57% (p=0.016 n=50+50) RegexpMatchHard_1K-4 47.4µs ± 4% 47.0µs ± 3% -0.82% (p=0.008 n=50+50) Revcomp-4 414ms ± 7% 412ms ± 7% ~ (p=0.285 n=50+50) Template-4 64.3ms ± 4% 62.7ms ± 3% -2.44% (p=0.000 n=50+50) TimeParse-4 316ns ± 3% 313ns ± 3% ~ (p=0.122 n=50+50) TimeFormat-4 291ns ± 3% 293ns ± 3% +0.80% (p=0.001 n=50+50) [Geo mean] 46.5µs 46.2µs -0.81% name old speed new speed delta GobDecode-4 118MB/s ± 6% 118MB/s ± 5% ~ (p=0.863 n=50+50) GobEncode-4 130MB/s ± 9% 128MB/s ± 8% ~ (p=0.076 n=50+50) Gzip-4 87.4MB/s ± 4% 86.8MB/s ± 7% -0.78% (p=0.002 n=50+50) Gunzip-4 531MB/s ± 5% 533MB/s ± 4% ~ (p=0.093 n=50+50) JSONEncode-4 210MB/s ± 4% 211MB/s ± 5% ~ (p=0.247 n=50+50) JSONDecode-4 39.8MB/s ± 4% 39.9MB/s ± 4% ~ (p=0.654 n=50+50) GoParse-4 18.1MB/s ± 5% 18.2MB/s ± 5% ~ (p=0.493 n=50+50) RegexpMatchEasy0_32-4 410MB/s ± 2% 413MB/s ± 3% +0.86% (p=0.004 n=50+50) RegexpMatchEasy0_1K-4 4.39GB/s ± 3% 4.38GB/s ± 3% ~ (p=0.063 n=50+50) RegexpMatchEasy1_32-4 432MB/s ± 3% 436MB/s ± 3% +1.07% (p=0.000 n=50+50) RegexpMatchEasy1_1K-4 2.77GB/s ± 2% 2.81GB/s ± 4% +1.46% (p=0.000 n=36+50) RegexpMatchMedium_32-4 9.16MB/s ± 3% 9.35MB/s ± 4% +2.09% (p=0.001 n=50+50) RegexpMatchMedium_1K-4 32.5MB/s ± 3% 33.2MB/s ± 3% +2.25% (p=0.000 n=50+50) RegexpMatchHard_32-4 20.4MB/s ± 3% 20.5MB/s ± 2% +0.56% (p=0.017 n=50+50) RegexpMatchHard_1K-4 21.6MB/s ± 4% 21.8MB/s ± 3% +0.83% (p=0.008 n=50+50) Revcomp-4 613MB/s ± 4% 618MB/s ± 7% ~ (p=0.152 n=48+50) Template-4 30.2MB/s ± 4% 30.9MB/s ± 3% +2.49% (p=0.000 n=50+50) [Geo mean] 127MB/s 128MB/s +0.64% Change-Id: If405198283855d75697f66cf894b2bef458f620e Reviewed-on: https://go-review.googlesource.com/135422Reviewed-by:
Keith Randall <khr@golang.org>
-
Iskander Sharipov authored
Change-Id: I5afba2c10372252be4b65dae7a95461722de904f Reviewed-on: https://go-review.googlesource.com/135835Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org> Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ben Shi authored
AMD64's ADDQconstmodify/ADDLconstmodify have similar logic with other constmodify like operators, but seperated case statements. This CL simplify them with a fallthrough. Change-Id: Ia73ffeaddc5080182f68c06c9d9b48fe32a14e38 Reviewed-on: https://go-review.googlesource.com/135855 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
- 18 Sep, 2018 11 commits
-
-
Jordan Rhee authored
Updates #26148 Change-Id: I8f68b2c926c7b11dc86c9664ed7ff2d2f78b64b4 Reviewed-on: https://go-review.googlesource.com/128715 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Rob Pike authored
The rules are subtle, but under some circumstances the result can be constant. Mention this and refer to the appropriate section of the specification. Fixes #27588. Change-Id: I4beaad036db87501378fb2ef48d216742d096933 Reviewed-on: https://go-review.googlesource.com/135519Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Keith Randall authored
That optimization is not valid if x == -0. The test is a bit tricky because 0 == -0. We distinguish 0 from -0 with 1/0 == inf, 1/-0 == -inf. This has been a bug since CL 24790 in Go 1.8. Probably doesn't warrant a backport. Fixes #27718 Note: the optimization x-0 -> x is actually valid. But it's probably best to take it out, so as to not confuse readers. Change-Id: I99f16a93b45f7406ec8053c2dc759a13eba035fa Reviewed-on: https://go-review.googlesource.com/135701Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Keith Randall authored
They aren't really races, or at least they don't have any observable effect. The spec is silent on whether these are actually races or not. Fix this problem by not using the address of len (or of cap) as the location where channel operations are recorded to occur. Use a random other field of hchan for that. I'm not 100% sure we should in fact fix this. Opinions welcome. Fixes #27070 Change-Id: Ib4efd4b62e0d1ef32fa51e373035ef207a655084 Reviewed-on: https://go-review.googlesource.com/135698Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Tobias Klauser authored
On Linux, sysUnused currently uses madvise(MADV_DONTNEED) to signal the kernel that a range of allocated memory contains unneeded data. After a successful call, the range (but not the data it contained before the call to madvise) is still available but the first access to that range will unconditionally incur a page fault (needed to 0-fill the range). A faster alternative is MADV_FREE, available since Linux 4.5. The mechanism is very similar, but the page fault will only be incurred if the kernel, between the call to madvise and the first access, decides to reuse that memory for something else. In sysUnused, test whether MADV_FREE is supported and fall back to MADV_DONTNEED in case it isn't. This requires making the return value of the madvise syscall available to the caller, so change runtime.madvise to return it. Fixes #23687 Change-Id: I962c3429000dd9f4a00846461ad128b71201bb04 Reviewed-on: https://go-review.googlesource.com/135395 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Alessandro Arzilli authored
For types defined as: type typename struct { ... } the linker produces two DIEs: (1) a DW_TAG_structure_type DIE and (2) a DW_TAG_typedef_type DIE having (1) as its type attribute. All subsequent references to 'typename' should use the DW_TAG_typedef_type DIE, not the DW_TAG_structure_type. Mostly this is true but sometimes one reference will use the DW_TAG_structure_type directly. In particular, this happens to the 'first' reference to the type in question (where 'first' means whatever happens first in the way the linker scans its symbols). This isn't only true of struct types: pointer types, array types, etc. can also be affected. This fix solves the problem by always returning the typedef DIE in newtype, when one is created. Fixes #27614 Change-Id: Ia65b4a1d8c2b752e33a4ebdb74ccd92faa69526e Reviewed-on: https://go-review.googlesource.com/134555 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Than McIntosh <thanm@google.com>
-
Ian Lance Taylor authored
Fixes #27731 Change-Id: Ifb4d57923b1bba0210ec1f623d779d7b5f442812 Reviewed-on: https://go-review.googlesource.com/135995 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Mark Rushakoff authored
The -mod=release flag is not supported, so this appears to be a documentation mistake. Fixes #27354. Change-Id: I895e8d5b4918adcb1f605361773173f312fa7b65 GitHub-Last-Rev: 42bfe0c11e38c90e76887771654ea81af98d50ec GitHub-Pull-Request: golang/go#27358 Reviewed-on: https://go-review.googlesource.com/132116 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Lynn Boger authored
Makes use of bounded shift information to generate more efficient shift instructions. Updates #25167 for ppc64x Change-Id: I7fc8d49a3fb3e0f273cc51bc767470b239cbdca7 Reviewed-on: https://go-review.googlesource.com/135380 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Munday <mike.munday@ibm.com>
-
Ivy Evans authored
Fixes missing commas where it wasn't immediately apparent whether "requests" was being used as a verb or a noun. Change-Id: Ic8c99b4f46475f40a6160d26a3cd11c215940dd5 GitHub-Last-Rev: 1becf6fabeb6f928e37526e96297dd60397ccf9b GitHub-Pull-Request: golang/go#27649 Reviewed-on: https://go-review.googlesource.com/135135Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com>
-
Iskander Sharipov authored
Change-Id: Idcd79788e64947a927af662b6394ac7218e62ba8 Reviewed-on: https://go-review.googlesource.com/135836Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-