- 20 Feb, 2018 7 commits
-
-
Ben Shi authored
A pair of MUL/NEG instructions can be combined to a single MNEG on ARM64. This CL implements this optimization. 1. A special test case gets big improvement. (https://github.com/benshi001/ugo1/blob/master/mneg_test.go) name old time/op new time/op delta MNEG-4 315µs ± 0% 260µs ± 0% -17.39% (p=0.000 n=24+25) 2. There is little change in the go1 benchmark, excluding noise. name old time/op new time/op delta BinaryTree17-4 42.2s ± 2% 41.9s ± 2% -0.82% (p=0.001 n=30+26) Fannkuch11-4 32.9s ± 0% 32.9s ± 0% -0.01% (p=0.006 n=20+26) FmtFprintfEmpty-4 541ns ± 3% 534ns ± 0% -1.24% (p=0.003 n=30+26) FmtFprintfString-4 1.09µs ± 0% 1.10µs ± 3% ~ (p=0.142 n=23+30) FmtFprintfInt-4 1.14µs ± 0% 1.14µs ± 0% ~ (p=0.435 n=24+24) FmtFprintfIntInt-4 1.76µs ± 0% 1.76µs ± 0% ~ (p=0.508 n=24+26) FmtFprintfPrefixedInt-4 2.20µs ± 3% 2.17µs ± 0% -1.10% (p=0.017 n=30+24) FmtFprintfFloat-4 3.28µs ± 0% 3.28µs ± 0% ~ (p=0.579 n=24+24) FmtManyArgs-4 7.30µs ± 0% 7.30µs ± 0% ~ (p=0.662 n=26+27) GobDecode-4 94.8ms ± 0% 94.8ms ± 0% +0.07% (p=0.010 n=25+23) GobEncode-4 80.9ms ± 4% 80.6ms ± 4% ~ (p=0.901 n=30+30) Gzip-4 4.45s ± 0% 4.49s ± 0% +0.98% (p=0.000 n=25+24) Gunzip-4 450ms ± 3% 443ms ± 0% ~ (p=0.942 n=30+26) HTTPClientServer-4 548µs ± 1% 551µs ± 1% +0.60% (p=0.000 n=29+30) JSONEncode-4 210ms ± 0% 211ms ± 0% +0.03% (p=0.000 n=23+25) JSONDecode-4 866ms ± 5% 877ms ± 5% ~ (p=0.187 n=30+30) Mandelbrot200-4 51.4ms ± 0% 52.0ms ± 3% +1.15% (p=0.001 n=24+30) GoParse-4 42.9ms ± 5% 41.9ms ± 0% -2.24% (p=0.000 n=30+26) RegexpMatchEasy0_32-4 1.02µs ± 3% 1.01µs ± 0% ~ (p=0.247 n=30+26) RegexpMatchEasy0_1K-4 3.90µs ± 0% 3.90µs ± 0% ~ (p=0.062 n=24+24) RegexpMatchEasy1_32-4 955ns ± 0% 956ns ± 0% +0.16% (p=0.000 n=25+23) RegexpMatchEasy1_1K-4 6.42µs ± 3% 6.37µs ± 0% -0.81% (p=0.012 n=30+24) RegexpMatchMedium_32-4 1.77µs ± 3% 1.79µs ± 0% +1.28% (p=0.003 n=30+24) RegexpMatchMedium_1K-4 561µs ± 0% 569µs ± 3% +1.50% (p=0.000 n=25+30) RegexpMatchHard_32-4 31.0µs ± 4% 30.8µs ± 0% ~ (p=1.000 n=26+26) RegexpMatchHard_1K-4 945µs ± 3% 945µs ± 3% ~ (p=0.513 n=30+30) Revcomp-4 7.76s ± 4% 7.68s ± 0% ~ (p=0.464 n=29+23) Template-4 903ms ± 5% 904ms ± 5% ~ (p=0.248 n=30+30) TimeParse-4 4.80µs ± 0% 4.80µs ± 0% ~ (p=0.081 n=25+26) TimeFormat-4 4.70µs ± 1% 4.70µs ± 1% ~ (p=0.763 n=24+26) [Geo mean] 709µs 708µs -0.09% name old speed new speed delta GobDecode-4 8.10MB/s ± 0% 8.09MB/s ± 0% ~ (p=0.160 n=25+23) GobEncode-4 9.49MB/s ± 4% 9.53MB/s ± 4% ~ (p=0.360 n=30+30) Gzip-4 4.36MB/s ± 0% 4.32MB/s ± 0% -0.92% (p=0.000 n=25+24) Gunzip-4 43.2MB/s ± 3% 43.8MB/s ± 0% ~ (p=0.980 n=30+26) JSONEncode-4 9.22MB/s ± 0% 9.22MB/s ± 0% -0.04% (p=0.005 n=23+25) JSONDecode-4 2.24MB/s ± 5% 2.21MB/s ± 4% ~ (p=0.252 n=30+30) GoParse-4 1.35MB/s ± 5% 1.38MB/s ± 0% +2.00% (p=0.003 n=30+26) RegexpMatchEasy0_32-4 31.5MB/s ± 3% 31.8MB/s ± 0% ~ (p=0.110 n=30+26) RegexpMatchEasy0_1K-4 263MB/s ± 0% 263MB/s ± 0% ~ (p=0.111 n=24+24) RegexpMatchEasy1_32-4 33.5MB/s ± 0% 33.4MB/s ± 0% -0.16% (p=0.003 n=25+23) RegexpMatchEasy1_1K-4 160MB/s ± 3% 161MB/s ± 0% +0.78% (p=0.012 n=30+24) RegexpMatchMedium_32-4 565kB/s ± 3% 560kB/s ± 0% -0.83% (p=0.001 n=30+24) RegexpMatchMedium_1K-4 1.83MB/s ± 0% 1.80MB/s ± 3% -1.56% (p=0.000 n=25+30) RegexpMatchHard_32-4 1.03MB/s ± 3% 1.04MB/s ± 0% +1.46% (p=0.000 n=30+26) RegexpMatchHard_1K-4 1.08MB/s ± 3% 1.09MB/s ± 3% ~ (p=0.444 n=30+30) Revcomp-4 32.8MB/s ± 4% 33.1MB/s ± 0% ~ (p=0.858 n=29+23) Template-4 2.15MB/s ± 5% 2.15MB/s ± 5% ~ (p=0.646 n=30+30) [Geo mean] 7.79MB/s 7.81MB/s +0.21% 3. There is no regression in the compilecmp benchmark. name old time/op new time/op delta Template 2.35s ± 4% 2.33s ± 3% ~ (p=0.796 n=10+10) Unicode 1.35s ± 6% 1.35s ± 5% ~ (p=1.000 n=9+10) GoTypes 8.10s ± 3% 8.14s ± 3% ~ (p=0.604 n=9+10) Compiler 40.5s ± 2% 40.2s ± 2% ~ (p=0.065 n=10+9) SSA 115s ± 2% 115s ± 2% ~ (p=0.447 n=9+10) Flate 1.45s ± 3% 1.45s ± 4% ~ (p=0.739 n=10+10) GoParser 1.85s ± 3% 1.86s ± 2% ~ (p=0.853 n=10+10) Reflect 5.11s ± 2% 5.10s ± 2% ~ (p=0.971 n=10+10) Tar 2.23s ± 5% 2.23s ± 3% ~ (p=0.796 n=10+10) XML 2.67s ± 2% 2.69s ± 2% ~ (p=0.549 n=9+10) [Geo mean] 5.00s 5.00s +0.02% name old user-time/op new user-time/op delta Template 2.88s ± 2% 2.86s ± 2% ~ (p=0.529 n=10+10) Unicode 1.70s ± 7% 1.69s ± 5% ~ (p=0.853 n=10+10) GoTypes 9.72s ± 1% 9.73s ± 1% ~ (p=0.684 n=10+10) Compiler 49.0s ± 1% 48.9s ± 1% ~ (p=0.631 n=10+10) SSA 144s ± 1% 144s ± 2% ~ (p=0.684 n=10+10) Flate 1.71s ± 4% 1.72s ± 4% ~ (p=0.853 n=10+10) GoParser 2.23s ± 2% 2.23s ± 2% ~ (p=0.971 n=10+10) Reflect 5.98s ± 2% 5.96s ± 2% ~ (p=0.481 n=10+10) Tar 2.68s ± 3% 2.67s ± 2% ~ (p=0.393 n=10+10) XML 3.21s ± 3% 3.22s ± 1% ~ (p=0.604 n=10+9) [Geo mean] 6.05s 6.05s -0.04% name old text-bytes new text-bytes delta HelloSize 641kB ± 0% 641kB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 9.46kB ± 0% 9.46kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 125kB ± 0% 125kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.24MB ± 0% 1.24MB ± 0% ~ (all equal) Change-Id: I9ed9128f0114e0f1ebb08ca2d042c90fcb2b1dcd Reviewed-on: https://go-review.googlesource.com/95075Reviewed-by:
Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Richard Miller authored
On Plan 9, the underlying create() syscall with DMDIR flag, which is used to implement Mkdir, will fail silently if the path exists and is not a directory. Work around this by checking for existence first and rejecting Mkdir with error EEXIST if the path is found. Fixes #23918 Change-Id: I439115662307923c9f498d3e7b1f32c6d205e1ad Reviewed-on: https://go-review.googlesource.com/94777Reviewed-by:
David du Colombier <0intro@gmail.com>
-
Mikio Hara authored
We live in the era of virtualization and isolation. There is no reason to hesitate to use IPv4 loopback address block for umbrella-type customer accommodating services. Fixes #23903 Change-Id: I990dd98e2651a993dac1b105c0bc771f8631cb93 Reviewed-on: https://go-review.googlesource.com/95336Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
philhofer authored
Introduce a new SSA pass to generate CondSelect intstrutions, and add CondSelect lowering rules for arm64. In order to make the CSEL instruction easier to optimize, and to simplify the introduction of CSNEG, CSINC, and CSINV in the future, modify the CSEL instruction to accept a condition code in the aux field. Notably, this change makes the go1 Gzip benchmark more than 10% faster. Benchmarks on a Cavium ThunderX: name old time/op new time/op delta BinaryTree17-96 15.9s ± 6% 16.0s ± 4% ~ (p=0.968 n=10+9) Fannkuch11-96 7.17s ± 0% 7.00s ± 0% -2.43% (p=0.000 n=8+9) FmtFprintfEmpty-96 208ns ± 1% 207ns ± 0% ~ (p=0.152 n=10+8) FmtFprintfString-96 379ns ± 0% 375ns ± 0% -0.95% (p=0.000 n=10+9) FmtFprintfInt-96 385ns ± 0% 383ns ± 0% -0.52% (p=0.000 n=9+10) FmtFprintfIntInt-96 591ns ± 0% 586ns ± 0% -0.85% (p=0.006 n=7+9) FmtFprintfPrefixedInt-96 656ns ± 0% 667ns ± 0% +1.71% (p=0.000 n=10+10) FmtFprintfFloat-96 967ns ± 0% 984ns ± 0% +1.78% (p=0.000 n=10+10) FmtManyArgs-96 2.35µs ± 0% 2.25µs ± 0% -4.63% (p=0.000 n=9+8) GobDecode-96 31.0ms ± 0% 30.8ms ± 0% -0.36% (p=0.006 n=9+9) GobEncode-96 24.4ms ± 0% 24.5ms ± 0% +0.30% (p=0.000 n=9+9) Gzip-96 1.60s ± 0% 1.43s ± 0% -10.58% (p=0.000 n=9+10) Gunzip-96 167ms ± 0% 169ms ± 0% +0.83% (p=0.000 n=8+9) HTTPClientServer-96 311µs ± 1% 308µs ± 0% -0.75% (p=0.000 n=10+10) JSONEncode-96 65.0ms ± 0% 64.8ms ± 0% -0.25% (p=0.000 n=9+8) JSONDecode-96 262ms ± 1% 261ms ± 1% ~ (p=0.579 n=10+10) Mandelbrot200-96 18.0ms ± 0% 18.1ms ± 0% +0.17% (p=0.000 n=8+10) GoParse-96 14.0ms ± 0% 14.1ms ± 1% +0.42% (p=0.003 n=9+10) RegexpMatchEasy0_32-96 644ns ± 2% 645ns ± 2% ~ (p=0.836 n=10+10) RegexpMatchEasy0_1K-96 3.70µs ± 0% 3.49µs ± 0% -5.58% (p=0.000 n=10+10) RegexpMatchEasy1_32-96 662ns ± 2% 657ns ± 2% ~ (p=0.137 n=10+10) RegexpMatchEasy1_1K-96 4.47µs ± 0% 4.31µs ± 0% -3.48% (p=0.000 n=10+10) RegexpMatchMedium_32-96 844ns ± 2% 849ns ± 1% ~ (p=0.208 n=10+10) RegexpMatchMedium_1K-96 179µs ± 0% 182µs ± 0% +1.20% (p=0.000 n=10+10) RegexpMatchHard_32-96 10.0µs ± 0% 10.1µs ± 0% +0.48% (p=0.000 n=10+9) RegexpMatchHard_1K-96 297µs ± 0% 297µs ± 0% -0.14% (p=0.000 n=10+10) Revcomp-96 3.08s ± 0% 3.13s ± 0% +1.56% (p=0.000 n=9+9) Template-96 276ms ± 2% 275ms ± 1% ~ (p=0.393 n=10+10) TimeParse-96 1.37µs ± 0% 1.36µs ± 0% -0.53% (p=0.000 n=10+7) TimeFormat-96 1.40µs ± 0% 1.42µs ± 0% +0.97% (p=0.000 n=10+10) [Geo mean] 264µs 262µs -0.77% Change-Id: Ie54eee4b3092af53e6da3baa6d1755098f57f3a2 Reviewed-on: https://go-review.googlesource.com/55670 Run-TryBot: Philip Hofer <phofer@umich.edu> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Ian Lance Taylor authored
Updates #23912 Change-Id: I50d06506a8ac91ed99a761a9ff3fd0b03d4c8121 Reviewed-on: https://go-review.googlesource.com/94995 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Url authored
Replace references to the obsoleted RFC 2616 with references to RFC 7230 through 7235, to avoid unnecessary confusion. Obvious inconsistencies are marked with todo comments. Updates #21974 Change-Id: I8fb4fcdd1333fc5193b93a2f09598f18c45e7a00 Reviewed-on: https://go-review.googlesource.com/94095Reviewed-by:
-
Keith Randall authored
When we go from a branch block to a plain block, reset the branch prediction bit. Downstream passes asssume that if the branch prediction is set, then the block has 2 successors. Fixes #23504 Change-Id: I2898ec002228b2e34fe80ce420c6939201c0a5aa Reviewed-on: https://go-review.googlesource.com/88955Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 19 Feb, 2018 9 commits
-
-
Alberto Donizetti authored
It appears that old code (from 2009) in xml.(*Decoder).rawToken replicates append's slice-growing functionality by allocating a new, bigger backing array and then calling copy. Simplifying the code by replacing it with a single append call does not seem to hurt performance: name old time/op new time/op delta Marshal-4 11.2µs ± 1% 11.3µs ±10% ~ (p=0.069 n=19+17) Unmarshal-4 28.6µs ± 1% 28.4µs ± 1% -0.60% (p=0.000 n=20+18) name old alloc/op new alloc/op delta Marshal-4 5.78kB ± 0% 5.78kB ± 0% ~ (all equal) Unmarshal-4 8.61kB ± 0% 8.27kB ± 0% -3.90% (p=0.000 n=20+20) name old allocs/op new allocs/op delta Marshal-4 23.0 ± 0% 23.0 ± 0% ~ (all equal) Unmarshal-4 189 ± 0% 190 ± 0% +0.53% (p=0.000 n=20+20) Change-Id: Ie580d1216a44760e611e63dee2c339af5465aea5 Reviewed-on: https://go-review.googlesource.com/86655Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Ahmet Soormally authored
The existing implementation declares a variable error which collides with builting type error. This change simply renames error variable to err. Change-Id: Ib56c2530f37f53ec70fdebb825a432d4c550cd04 Reviewed-on: https://go-review.googlesource.com/87775Reviewed-by:
-
Daniel Martí authored
It's always nil, so simplify its signature. Found with unparam. Change-Id: I45dd0f868ec2f5de98a970776be686417c8d73b6 Reviewed-on: https://go-review.googlesource.com/95235 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Keith Randall authored
Instead of (And64 x x) -> x (And32 x x) -> x (And16 x x) -> x (And8 x x) -> x we can now do: (And(64|32|16|8) x x) -> x Any part of an opcode can have a parenthesized, |-separated list of possibilites. The rule is then expanded using each piece of the | combo. If there are multiple | clauses, they get expanded in tandem. (All the first positions, then all the second positions, etc.) All places | opcodes appear must have the same count. A more complicated example: (MOV(L|SS)load [off1] {sym1} (LEAQ4 [off2] {sym2} ptr idx) mem) && is32Bit(off1+off2) && canMergeSym(sym1, sym2) -> (MOV(L|SS)loadidx4 [off1+off2] {mergeSym(sym1,sym2)} ptr idx mem) This meta-rule generates 2 rules, a MOVL and a MOVSS rule. This CL is carefully orchestrated to not change the generated rules file at all. In some cases, this means we can't align the rules nicely because it changes the whitespace in the generated code. I'll clean that up as a separate step. There are many more opportunites to compactify rules using this new mechanism. I've just done some examples, there's more to do. Change-Id: I8a5e748cd0761ccbb12d09b01925b2f1f4b2f608 Reviewed-on: https://go-review.googlesource.com/86595 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Daniel Martí authored
By grepping for ]string{$, one can find many manual implementations of stringer. The debug/dwarf ones needed the new -trimprefix flag, too. html/template was fairly simple, just implementing the fallback as stringer would. The changes there are trivial. The ones in debug/dwarf needed a bit of extra logic since the GoString wants to use its own format, depending on whether or not the value is one of the known constants. Change-Id: I501ea7deaa538fa425c8e9c2bb895f480169273f Reviewed-on: https://go-review.googlesource.com/77253 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Daniel Martí authored
reflect.Value is a struct and does not have a kind nor any flag for untyped nils. As a result, it is tricky to differentiate when we're missing a value, from when we have one but it is untyped nil. We could start using *reflect.Value instead, to add one level of indirection, using nil for missing values and new(reflect.Value) for untyped nils. However, that is a fairly invasive change, and would also mean unnecessary allocations. Instead, use a special reflect.Value that depicts when a value is missing. This is the case for the "final" reflect.Value in multiple scenarios, such as the start of a pipeline. Give it a specific, unexported type too, to make sure it cannot be mistaken for any other valid value. Finally, replace "final.IsValid()" with "final != missingVal", since final.IsValid() will be false when final is an untyped nil. Also add a few test cases, all different variants of the untyped nil versus missing value scenario. Fixes #18716. Change-Id: Ia9257a84660ead5a7007fd1cced7782760b62d9d Reviewed-on: https://go-review.googlesource.com/95215 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Daniel Martí authored
Noticed while reading some code. Change-Id: I63f8c7a453d4895583a8ffc13bec57385b6944aa Reviewed-on: https://go-review.googlesource.com/95195 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
Avoid using make in gobytes which clears the byte slice backing array unnecessarily since the content is overwritten immediately again. Check that the user provided length is positive and below the maximum allowed allocation size explicitly in gobytes as this was done in makeslice before this change. Fixes #23634 Change-Id: Id852619e932aabfc468871c42ad07d34da91f45c Reviewed-on: https://go-review.googlesource.com/94760 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Yazen2017 authored
The fourth example for map indexing states you have a map of type [K]V and attempts to read in a variable of type T. Further, the example is meant to showcase the boolean return variable saying whether the map contained a key, but overrides to type T. This will not compile. Changed last updated date to February 18 Fixes: #23895 Change-Id: I63c52adbcd989afd4855e329e6c727f4c01f7881 Reviewed-on: https://go-review.googlesource.com/94906Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 18 Feb, 2018 2 commits
-
-
Kunpei Sakai authored
Change-Id: I1f25b11fb9b7cd3c09968ed99913dc85db2025ef Reviewed-on: https://go-review.googlesource.com/94976Reviewed-by:
-
Mansour Rahimi authored
Calling MkdirAll on paths in extended-length form (\\?\-prefixed) failed. MkdirAll calls itself recursively with parent directory of given path in its parameter. It finds parent directory by looking for delimiter in the path, and taking the left part. When path is in extended-length form, it finds empty path at the end. Here is a sample of path in extended-length form: \\?\c:\foo\bar This change fixes that by passing trailing path separator to MkdirAll (so it works for path like \\?\c:\). Fixes #22230 Change-Id: I363660b262588c5382ea829773d3b6005ab8df3c Reviewed-on: https://go-review.googlesource.com/86295Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 17 Feb, 2018 9 commits
-
-
Tobias Klauser authored
Follow CL 93655 which removed the (commented-out) usage of this function. Also remove unused constant _RLIMIT_AS and type rlimit. Change-Id: Ifb6e6b2104f4c2555269f8ced72bfcae24f5d5e9 Reviewed-on: https://go-review.googlesource.com/94775 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Yury Smolsky authored
Updated docs that go run does not return the exit code of the compiled binary. Fixes #23716 Change-Id: Ib85459974c4c6d2760ddba957ef711628098661f Reviewed-on: https://go-review.googlesource.com/94795Reviewed-by:
-
Martin Möhrmann authored
Overall code is unchanged. The functions for different types (32, 64, str) of map fast routines are collected in map_fast.go that has grown to ~1300 lines. Moving the functions for each map fast type into a separate file allows for an easier overview and navigation within the map code. Change-Id: Ic09e4212f9025a66a10b11ef8dac23ad49d1d5ae Reviewed-on: https://go-review.googlesource.com/90335 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
One of the variables declared in cleantempnopop named 'kill' does not hold a OVARKILL node but an OVARLIVE node. Rename that variable to 'live' to differentiate it from the other variable named kill that holds a OVARKILL node. Passes toolstash -cmp. Change-Id: I34c8729e5c303b8cdabe44c9af980d4f16000e4b Reviewed-on: https://go-review.googlesource.com/88816 Run-TryBot: Martin Möhrmann <moehrmann@google.com> Reviewed-by:
-
Martin Möhrmann authored
Rename all map implementation and test files to use "map" as a file name prefix instead of "hashmap" for the implementation and "map" for the test file names. Change-Id: I7b317c1f7a660b95c6d1f1a185866f2839e69446 Reviewed-on: https://go-review.googlesource.com/90336 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Andrew Bonventre authored
Change-Id: I869f1607b0209ad190bc02999879f0682965fdf7 Reviewed-on: https://go-review.googlesource.com/94915Reviewed-by:
-
Ian Lance Taylor authored
Fixes #23875 Change-Id: I503af71f44d11cd6b787fef100246b55735614a0 Reviewed-on: https://go-review.googlesource.com/94896 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Kyo authored
Change-Id: Ie4d23cdb81473a4c989a977a127479cf825084dc Reviewed-on: https://go-review.googlesource.com/77850Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Arthur Khashaev authored
Fixes #23867, CVE-2018-7187 Change-Id: I5d0ba4923c9ed354ef76290e149c182447f9dfe2 Reviewed-on: https://go-review.googlesource.com/94656 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 16 Feb, 2018 7 commits
-
-
Ian Lance Taylor authored
Before this change, when using -insecure, we permitted any meta import repo root as long as it contained "://". When not using -insecure, we restrict meta import repo roots to be valid URLs. People may depend on that somehow, so permit meta import repo roots to be invalid URLs, but require them to have valid schemes per RFC 3986. Fixes #23867 Change-Id: Iac666dfc75ac321bf8639dda5b0dba7c8840922d Reviewed-on: https://go-review.googlesource.com/94603Reviewed-by:
-
Richard Miller authored
This test was sometimes timing out on the plan9/arm builder (raspberry pi) when run in parallel with other network intensive tests. It appears that tcp on the loopback interface could do with some tuning for better performance on Plan 9, but until that's done, increasing the timeout from 5 to 10 seconds allows this test to pass. This should have no effect on other platforms where 5 seconds was already enough. Change-Id: If310ee569cae8ca8f56346d84ce23803feb23a41 Reviewed-on: https://go-review.googlesource.com/94796Reviewed-by:
-
Richard Miller authored
On Plan 9, sysReserve was ignoring the address hint and allocating memory wherever it is available. This causes the new TestArenaCollision test to fail on 32-bit Plan 9. We now use the address hint in the specific case where sysReserve is extending the process address space at its end, and similarly we contract the address space in the case where sysFree is releasing memory at the end. Fixes #23860 Change-Id: Ia5254779ba8f1698c999832720a88de400b5f91a Reviewed-on: https://go-review.googlesource.com/94776Reviewed-by:
-
Chad Rosier authored
name old time/op new time/op delta Ceil 550ns ± 0% 486ns ± 7% -11.64% (p=0.000 n=13+18) Floor 495ns ±19% 512ns ±12% ~ (p=0.164 n=20+20) Round 550ns ± 0% 487ns ± 8% -11.49% (p=0.000 n=12+19) Trunc 563ns ± 7% 488ns ±13% -13.44% (p=0.000 n=15+2) Change-Id: I53f234b160b3c026a277506e2cf977d150379464 Reviewed-on: https://go-review.googlesource.com/88295 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Elias Naur authored
Replace the test for nacl with testenv.MustHaveExec to also skip test on iOS. Change-Id: I6822714f6d71533d1b18bbb7894f6ad339d8aea1 Reviewed-on: https://go-review.googlesource.com/94755 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
It's used on Solaris to import symbols from shared libraries, e.g., in golang.org/x/sys/unix and golang.org/x/net/internal/socket. We could use a different directive but that would require build tags in all the places that use it. Updates #23672 Updates #23749 Change-Id: I47fcf72a6d2862e304204705979c2056c2f78ec5 Reviewed-on: https://go-review.googlesource.com/94018 Run-TryBot: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Updates #23672 Updates #23749 Change-Id: I85b6493bd1e4095398508b7ef395c35463dfbde1 Reviewed-on: https://go-review.googlesource.com/94158Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
- 15 Feb, 2018 6 commits
-
-
Balaram Makam authored
This adds math/bits intrinsics for OnesCount on arm64. name old time/op new time/op delta OnesCount 3.81ns ± 0% 1.60ns ± 0% -57.96% (p=0.000 n=7+8) OnesCount8 1.60ns ± 0% 1.60ns ± 0% ~ (all equal) OnesCount16 2.41ns ± 0% 1.60ns ± 0% -33.61% (p=0.000 n=8+8) OnesCount32 4.17ns ± 0% 1.60ns ± 0% -61.58% (p=0.000 n=8+8) OnesCount64 3.80ns ± 0% 1.60ns ± 0% -57.84% (p=0.000 n=8+8) Update #18616 Conflicts: src/cmd/compile/internal/gc/asm_test.go Change-Id: I63ac2f63acafdb1f60656ab8a56be0b326eec5cb Reviewed-on: https://go-review.googlesource.com/90835 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:
-
Matthew Dempsky authored
Slightly simpler. Change-Id: Ic3a96675c56cc8c2e336b932536c2247f8cbb96d Reviewed-on: https://go-review.googlesource.com/39996 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Austin Clements authored
Now that we have memLimit, also having _MaxMem is a bit confusing. Replace it with maxAlloc, which better conveys what it limits. We also define maxAlloc slightly differently: since it's now clear that it limits allocation size, we can account for a subtle difference between 32-bit and 64-bit. Change-Id: Iac39048018cc0dae7f0919e25185fee4b3eed529 Reviewed-on: https://go-review.googlesource.com/85890 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently there's a detailed comment in lfstack_64bit.go about address space limitations on various architectures. Since that's now relevant to malloc, move it to a more prominent place in the documentation for memLimitBits. Updates #10460. Change-Id: If9708291cf3a288057b8b3ba0ba6a59e3602bbd6 Reviewed-on: https://go-review.googlesource.com/85889 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently large sysReserve calls on some OSes don't actually reserve the memory, but just check that it can be reserved. This was important when we called sysReserve to "reserve" many gigabytes for the heap up front, but now that we map memory in small increments as we need it, this complication is no longer necessary. This has one curious side benefit: currently, on Linux, allocations that are large enough to be rejected by mmap wind up freezing the application for a long time before it panics. This happens because sysReserve doesn't reserve the memory, so sysMap calls mmap_fixed, which calls mmap, which fails because the mapping is too large. However, mmap_fixed doesn't inspect *why* mmap fails, so it falls back to probing every page in the desired region individually with mincore before performing an (otherwise dangerous) MAP_FIXED mapping, which will also fail. This takes a long time for a large region. Now this logic is gone, so the mmap failure leads to an immediate panic. Updates #10460. Change-Id: I8efe88c611871cdb14f99fadd09db83e0161ca2e Reviewed-on: https://go-review.googlesource.com/85888 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
This replaces the contiguous heap arena mapping with a potentially sparse mapping that can support heap mappings anywhere in the address space. This has several advantages over the current approach: * There is no longer any limit on the size of the Go heap. (Currently it's limited to 512GB.) Hence, this fixes #10460. * It eliminates many failures modes of heap initialization and growing. In particular it eliminates any possibility of panicking with an address space conflict. This can happen for many reasons and even causes a low but steady rate of TSAN test failures because of conflicts with the TSAN runtime. See #16936 and #11993. * It eliminates the notion of "non-reserved" heap, which was added because creating huge address space reservations (particularly on 64-bit) led to huge process VSIZE. This was at best confusing and at worst conflicted badly with ulimit -v. However, the non-reserved heap logic is complicated, can race with other mappings in non-pure Go binaries (e.g., #18976), and requires that the entire heap be either reserved or non-reserved. We currently maintain the latter property, but it's quite difficult to convince yourself of that, and hence difficult to keep correct. This logic is still present, but will be removed in the next CL. * It fixes problems on 32-bit where skipping over parts of the address space leads to mapping huge (and never-to-be-used) metadata structures. See #19831. This also completely rewrites and significantly simplifies mheap.sysAlloc, which has been a source of many bugs. E.g., #21044, #20259, #18651, and #13143 (and maybe #23222). This change also makes it possible to allocate individual objects larger than 512GB. As a result, a few tests that expected huge allocations to fail needed to be changed to make even larger allocations. However, at the moment attempting to allocate a humongous object may cause the program to freeze for several minutes on Linux as we fall back to probing every page with addrspace_free. That logic (and this failure mode) will be removed in the next CL. Fixes #10460. Fixes #22204 (since it rewrites the code involved). This slightly slows down compilebench and the x/benchmarks garbage benchmark. name old time/op new time/op delta Template 184ms ± 1% 185ms ± 1% ~ (p=0.065 n=10+9) Unicode 86.9ms ± 3% 86.3ms ± 1% ~ (p=0.631 n=10+10) GoTypes 599ms ± 0% 602ms ± 0% +0.56% (p=0.000 n=10+9) Compiler 2.87s ± 1% 2.89s ± 1% +0.51% (p=0.002 n=9+10) SSA 7.29s ± 1% 7.25s ± 1% ~ (p=0.182 n=10+9) Flate 118ms ± 2% 118ms ± 1% ~ (p=0.113 n=9+9) GoParser 147ms ± 1% 148ms ± 1% +1.07% (p=0.003 n=9+10) Reflect 401ms ± 1% 404ms ± 1% +0.71% (p=0.003 n=10+9) Tar 175ms ± 1% 175ms ± 1% ~ (p=0.604 n=9+10) XML 209ms ± 1% 210ms ± 1% ~ (p=0.052 n=10+10) (https://perf.golang.org/search?q=upload:20171231.4) name old time/op new time/op delta Garbage/benchmem-MB=64-12 2.23ms ± 1% 2.25ms ± 1% +0.84% (p=0.000 n=19+19) (https://perf.golang.org/search?q=upload:20171231.3) Relative to the start of the sparse heap changes (starting at and including "runtime: fix various contiguous bitmap assumptions"), overall slowdown is roughly 1% on GC-intensive benchmarks: name old time/op new time/op delta Template 183ms ± 1% 185ms ± 1% +1.32% (p=0.000 n=9+9) Unicode 84.9ms ± 2% 86.3ms ± 1% +1.65% (p=0.000 n=9+10) GoTypes 595ms ± 1% 602ms ± 0% +1.19% (p=0.000 n=9+9) Compiler 2.86s ± 0% 2.89s ± 1% +0.91% (p=0.000 n=9+10) SSA 7.19s ± 0% 7.25s ± 1% +0.75% (p=0.000 n=8+9) Flate 117ms ± 1% 118ms ± 1% +1.10% (p=0.000 n=10+9) GoParser 146ms ± 2% 148ms ± 1% +1.48% (p=0.002 n=10+10) Reflect 398ms ± 1% 404ms ± 1% +1.51% (p=0.000 n=10+9) Tar 173ms ± 1% 175ms ± 1% +1.17% (p=0.000 n=10+10) XML 208ms ± 1% 210ms ± 1% +0.62% (p=0.011 n=10+10) [Geo mean] 369ms 373ms +1.17% (https://perf.golang.org/search?q=upload:20180101.2) name old time/op new time/op delta Garbage/benchmem-MB=64-12 2.22ms ± 1% 2.25ms ± 1% +1.51% (p=0.000 n=20+19) (https://perf.golang.org/search?q=upload:20180101.3) Change-Id: I5daf4cfec24b252e5a57001f0a6c03f22479d0f0 Reviewed-on: https://go-review.googlesource.com/85887 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
