- 19 Apr, 2017 29 commits
-
-
Josh Bleecher Snyder authored
Fixes #20014 Change-Id: Ie58d3e989f2d7388b3d8849fbcfbceed3c6aa084 Reviewed-on: https://go-review.googlesource.com/41132 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Change-Id: Ie8fd7839806b4a6bcfac5ac1f984db7ab282c3b5 Reviewed-on: https://go-review.googlesource.com/41150 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
David Lazar <lazard@golang.org>
-
Robert Griesemer authored
- PkgMap was only needed to test import/export in a "cleanroom" environment, with debugFormat set. Provided helper function instead. - PkgList was only used to identify directly imported packages. Instead, compute that list explicitly from the package map. It happens only once, the list is small, and it's more robust than keeping two data structures in sync. Change-Id: I82dce3c0b5cb816faae58708e877799359c20fcb Reviewed-on: https://go-review.googlesource.com/41078Reviewed-by:
-
Robert Griesemer authored
There's already special code to access it. Change-Id: I28ca4f44a04262407ee9f1c826ada4e7eba44775 Reviewed-on: https://go-review.googlesource.com/41073Reviewed-by:
-
Robert Griesemer authored
Change-Id: I08b43b08a8d2e9851f41401feee4b72287ced774 Reviewed-on: https://go-review.googlesource.com/41072Reviewed-by:
-
Robert Griesemer authored
That's where it belongs. Also, moved pkgMap and pkgs globals. Change-Id: I531727fe5ce162c403efefec82f4cc90afa326d7 Reviewed-on: https://go-review.googlesource.com/41071Reviewed-by:
-
Daniel Martí authored
Returns at the end of func bodies where the funcs have no return values are pointless. Change-Id: I0da5ea78671503e41a9f56dd770df8c919310ce5 Reviewed-on: https://go-review.googlesource.com/41093 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Aliaksandr Valialkin authored
Such dead code is legitimate when dealing with arch-specific types (int, uint, uintptr). The CL removes the majority of 'too small for shift' false positives from such a code. Change-Id: I62c5635a1d3774ab2d71d3d7056f0589f214cbe5 Reviewed-on: https://go-review.googlesource.com/38065 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Michael Munday authored
When we switched to SSA R0 was made allocatable and no longer holds zero on s390x. Change-Id: I1c752bb02da35462a535492379345fa9f4e12cb0 Reviewed-on: https://go-review.googlesource.com/41079Reviewed-by:
-
Austin Clements authored
This displays the swept and reclaimed bytes for sweep events in the lower panel of the trace viewer. Change-Id: If1665a1c02bbc47700e0d9f515e574f013f3f285 Reviewed-on: https://go-review.googlesource.com/40812 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This extends the GCSweepDone event with counts of swept and reclaimed bytes. These are useful for understanding the duration and effectiveness of sweep events. Change-Id: I3c97a4f0f3aad3adbd188adb264859775f54e2df Reviewed-on: https://go-review.googlesource.com/40811 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently, each individual span sweep emits a span to the trace. But sweeps are generally done in loops until some condition is satisfied, so this tracing is lower-level than anyone really wants any hides the fact that no other work is being accomplished between adjacent sweep events. This is also high overhead: enabling tracing significantly impacts sweep latency. Replace this with instead tracing around the sweep loops used for allocation. This is slightly tricky because sweep loops don't generally know if any sweeping will happen in them. Hence, we make the tracing lazy by recording in the P that we would like to start tracing the sweep *if* one happens, and then only closing the sweep event if we started it. This does mean we don't get tracing on every sweep path, which are legion. However, we get much more informative tracing on the paths that block allocation, which are the paths that matter. Change-Id: I73e14fbb250acb0c9d92e3648bddaa5e7d7e271c Reviewed-on: https://go-review.googlesource.com/40810 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Michael Munday authored
Changes the text to match GOOS which appends 'and so on' at the end to avoid restricting the set of possible values. Change-Id: I54bcde71334202cf701662cdc2582c974ba8bf53 Reviewed-on: https://go-review.googlesource.com/41074Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Adam Langley authored
Patch from Vlad Krasnov and confirmed to be under CLA. Fixes #20040. Change-Id: Ieb8436c4dcb6669a1620f1e0d257efd047b1b87c Reviewed-on: https://go-review.googlesource.com/41070 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
When allocating a non-small array of buckets for a map, also preallocate some overflow buckets. The estimate of the number of overflow buckets is based on a simulation of putting mid=(low+high)/2 elements into a map, where low is the minimum number of elements needed to reach this value of b (according to overLoadFactor), and high is the maximum number of elements possible to put in this value of b (according to overLoadFactor). This estimate is surprisingly reliable and accurate. The number of overflow buckets needed is quadratic, for a fixed value of b. Using this mid estimate means that we will overallocate a few too many overflow buckets when the actual number of elements is near low, and underallocate significantly too few overflow buckets when the actual number of elements is near high. The mechanism introduced in this CL can be re-used for other overflow bucket optimizations. For example, given an initial size hint, we could estimate quite precisely the number of overflow buckets. This is #19931. We could also change from "non-nil means end-of-list" to "pointer-to-hmap.buckets means end-of-list", and then create a linked list of reusable overflow buckets when they are freed by map growth. That is #19992. We could also use a similar mechanism to do bulk allocation of overflow buckets. All these uses can co-exist with only the one additional pointer in mapextra, given a little care. name old time/op new time/op delta MapPopulate/1-8 60.1ns ± 2% 60.3ns ± 2% ~ (p=0.278 n=19+20) MapPopulate/10-8 577ns ± 1% 578ns ± 1% ~ (p=0.140 n=20+20) MapPopulate/100-8 8.06µs ± 1% 8.19µs ± 1% +1.67% (p=0.000 n=20+20) MapPopulate/1000-8 104µs ± 1% 104µs ± 1% ~ (p=0.317 n=20+20) MapPopulate/10000-8 891µs ± 1% 888µs ± 1% ~ (p=0.101 n=19+20) MapPopulate/100000-8 8.61ms ± 1% 8.58ms ± 0% -0.34% (p=0.009 n=20+17) name old alloc/op new alloc/op delta MapPopulate/1-8 0.00B 0.00B ~ (all equal) MapPopulate/10-8 179B ± 0% 179B ± 0% ~ (all equal) MapPopulate/100-8 3.33kB ± 0% 3.38kB ± 0% +1.48% (p=0.000 n=20+16) MapPopulate/1000-8 55.5kB ± 0% 53.4kB ± 0% -3.84% (p=0.000 n=19+20) MapPopulate/10000-8 432kB ± 0% 428kB ± 0% -1.06% (p=0.000 n=19+20) MapPopulate/100000-8 3.65MB ± 0% 3.62MB ± 0% -0.70% (p=0.000 n=20+20) name old allocs/op new allocs/op delta MapPopulate/1-8 0.00 0.00 ~ (all equal) MapPopulate/10-8 1.00 ± 0% 1.00 ± 0% ~ (all equal) MapPopulate/100-8 18.0 ± 0% 17.0 ± 0% -5.56% (p=0.000 n=20+20) MapPopulate/1000-8 96.0 ± 0% 72.6 ± 1% -24.38% (p=0.000 n=20+20) MapPopulate/10000-8 625 ± 0% 319 ± 0% -48.86% (p=0.000 n=20+20) MapPopulate/100000-8 6.23k ± 0% 4.00k ± 0% -35.79% (p=0.000 n=20+20) Change-Id: I01f41cb1374bdb99ccedbc00d04fb9ae43daa204 Reviewed-on: https://go-review.googlesource.com/40979 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Josh Bleecher Snyder authored
Updates #19931 Updates #19992 Change-Id: Ib2d4e6b9b89a49caa443310d896dce8d6db06050 Reviewed-on: https://go-review.googlesource.com/40978 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
bmap already has a overflow (getter) method. Add a setoverflow (setter) method, for readability. Updates #19931 Updates #19992 Change-Id: I00b3d94037c0d75508a7ebd51085c5c3857fb764 Reviewed-on: https://go-review.googlesource.com/40977 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Any change to how we allocate overflow buckets will require some extra hmap storage, but we don't want hmap to grow, particular as small maps usually don't need overflow buckets. This CL converts the existing hmap overflow field, which is usually used for pointer-free maps, into a generic extra field. This extra field can be used to hold data that is optional. If it is valuable enough to do have special handling of overflow buckets, which are medium-sized, it is valuable enough to pay an extra alloc and two extra words for. Adding fields to extra would entail adding overhead to pointer-free maps; any mapextra fields added would need to be weighed against that. This CL is just rearrangement, though. Updates #19931 Updates #19992 Change-Id: If8537a206905b9d4dc6cd9d886184ece671b3f80 Reviewed-on: https://go-review.googlesource.com/40976 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This simplifies the code, as well as providing a single place to modify to change the allocation of new overflow buckets. Updates #19931 Updates #19992 Change-Id: I77070619f5c8fe449bbc35278278bca5eda780f2 Reviewed-on: https://go-review.googlesource.com/40975 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Todd Neal authored
goobj.importPathToPrefix is 3x faster than gc.pathToPrefix so rename and move it to cmd/internal/objabi which is already imported by both goobj and gc. Change-Id: I10eda5bce95ef6d5d888818c5c47258c2833ea45 Reviewed-on: https://go-review.googlesource.com/40875 Run-TryBot: Todd Neal <todd@tneal.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
xufei_Alex authored
Change-Id: I8e90012b3498c51aaeb2f70182debab52549afb4 Reviewed-on: https://go-review.googlesource.com/40930Reviewed-by:
-
Dave Cheney authored
The last use of condOps was removed in c644a76e. Change-Id: I5383d0e7a9078fc17ca12ed032ecf8e7f4aa95d7 Reviewed-on: https://go-review.googlesource.com/41030 Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Chase authored
Replace derecursed postorder computation with one that mimics DFS traversal. Corrected outerinner function in loopfinder Leave enhanced checks in place. Change-Id: I657ba5e89c88941028d6d4c72e9f9056e30f1ce8 Reviewed-on: https://go-review.googlesource.com/40872 Run-TryBot: David Chase <drchase@google.com> Reviewed-by:
-
Robert Griesemer authored
Follow-up on https://go-review.googlesource.com/#/c/39998/. Change-Id: I97f8e31ca923685198984ad64f952d6dc8208edf Reviewed-on: https://go-review.googlesource.com/40982 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Marvin Stenger <marvin.stenger94@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Follow-up on https://go-review.googlesource.com/#/c/39998/ which dropped this information. The reported blocks are the innermost blocks containing a label jumped to from outside, not the outermost block as reported originally by cmd/compile. We could report the outermost block with a slighly more involved algorithm (need to track containing blocks for all unresolved forward gotos), but since gccgo also reports the innermost blocks, the current approach seems good enough. Change-Id: Ic0235b8fafe8d5f99dc9872b58e90e8d9e72c5db Reviewed-on: https://go-review.googlesource.com/40980 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Todd Neal authored
zbootstrap.go was moved in 1e3570ac. This updates .gitignore to match. Change-Id: I7500e0abc8e60b6c36c6ae056b2f68b9d021fc6f Reviewed-on: https://go-review.googlesource.com/40993 Run-TryBot: Todd Neal <todd@tneal.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Follow-up on https://go-review.googlesource.com/#/c/39998/. Change-Id: I8830eebd7ea7e02b7edda99e67b6d43529401201 Reviewed-on: https://go-review.googlesource.com/40974Reviewed-by:
-
Robert Griesemer authored
Instead of a separate check control flow pass (checkcfg.go) operating on nodes, perform this check at parse time on the new syntax tree. Permits this check to be done concurrently, and doesn't depend on the specifics of the symbol's dclstack implementation anymore. The remaining dclstack uses will be removed in a follow-up change. - added CheckBranches Mode flag (so we can turn off the check if we only care about syntactic correctness, e.g. for tests) - adjusted test/goto.go error messages: the new branches checker only reports if a goto jumps into a block, but not which block (we may want to improve this again, eventually) - also, the new branches checker reports one variable that is being jumped over by a goto, but it may not be the first one declared (this is fine either way) - the new branches checker reports additional errors for fixedbugs/issue14006.go (not crucial to avoid those errors) - the new branches checker now correctly reports only variable declarations being jumped over, rather than all declarations (issue 8042). Added respective tests. Fixes #8042. Change-Id: I53b6e1bda189748e1e1fb5b765a8a64337c27d40 Reviewed-on: https://go-review.googlesource.com/39998Reviewed-by:
-
Matthew Dempsky authored
Now only cmd/asm and cmd/compile depend on cmd/internal/obj. Changing the assembler backends no longer requires reinstalling cmd/link or cmd/addr2line. There's also now one canonical definition of the object file format in cmd/internal/objabi/doc.go, with a warning to update all three implementations. objabi is still something of a grab bag of unrelated code (e.g., flag and environment variable handling probably belong in a separate "tool" package), but this is still progress. Fixes #15165. Fixes #20026. Change-Id: Ic4b92fac7d0d35438e0d20c9579aad4085c5534c Reviewed-on: https://go-review.googlesource.com/40972 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 18 Apr, 2017 11 commits
-
-
Alexander Menzhinsky authored
Now cgo reads source files twice: for c prefix generation and parsing go code to an ast node. It can be narrowed down to single loop. Change-Id: Ie05452a3a12106aaab863244727390037e69e8e6 Reviewed-on: https://go-review.googlesource.com/40939Reviewed-by:
-
Josh Bleecher Snyder authored
Someday we should write errchk in Go. But not today. Fixes #20007 Change-Id: I61ccf3cfaa66a710782f8a2212a6a2b4040698da Reviewed-on: https://go-review.googlesource.com/40950 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alexander Menzhinsky authored
Here we restrict using cgo builtin references because internally they're go functions as opposed to C usafe.Pointer values. Fixes #18889 Change-Id: I1e4332e4884063ccbaf9772c172d4462ec8f3d13 Reviewed-on: https://go-review.googlesource.com/40934Reviewed-by:
-
Michael Hudson-Doyle authored
Just noticed this in passing. Change-Id: I58fa828ef58598209ed4cbe4abc6f9f02ffc4844 Reviewed-on: https://go-review.googlesource.com/40896 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Lazar authored
TestMultiReaderFlatten determines the call depth by counting PCs returned by runtime.Callers. With inlining, this is incorrect because a PC can represent multiple calls. Furthermore, runtime.Callers might return an additional "skip" PC, which does not represent a real call. This modifies the test to use CallersFrames to determine the call depth. Now the test passes with -l=4. Change-Id: I284f3b1e0b2d194bd08c230c616914503e5a370d Reviewed-on: https://go-review.googlesource.com/40990 Run-TryBot: David Lazar <lazard@golang.org> Reviewed-by:
Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Lazar authored
Only the noinline pragma on testCallerFoo is needed to pass the test, but the second pragma makes the test robust to future changes to the inliner. Change-Id: I80b384380c598f52e0382f53b59bb47ff196363d Reviewed-on: https://go-review.googlesource.com/40877 Run-TryBot: David Lazar <lazard@golang.org> Reviewed-by:
-
David Lazar authored
Otherwise, with -l=4, runtime.Callers gets inlined and the example prints too many frames. Now the example passes with -l=4. Change-Id: I9e420af9371724ac3ec89efafd76a658cf82bb4a Reviewed-on: https://go-review.googlesource.com/40876 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Lazar authored
This rewrites runtime.Caller in terms of stackExpander, which already handles inlined frames and partially skipped frames. This also has the effect of making runtime.Caller understand cgo frames if there is a cgo symbolizer. Updates #19348. Change-Id: Icdf4df921aab5aa394d4d92e3becc4dd169c9a6e Reviewed-on: https://go-review.googlesource.com/40270 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
CL 27254 changed hextable to a byte array for performance. CL 28219 fixed the compiler so that that is no longer necessary. As Kirill notes in #15808, a string is preferable as the linker can easily de-dup it. So go back. No performance changes. Change-Id: Ibef7d21d0f2507968a0606602c5dd57ed4a85b1b Reviewed-on: https://go-review.googlesource.com/40970 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Matthew Dempsky authored
Automated refactoring using github.com/mdempsky/unbed (to rewrite s.Foo to s.FuncInfo.Foo) and then gorename (to rename the FuncInfo field to just Func). Passes toolstash-check -all. Change-Id: I802c07a1239e0efea058a91a87c5efe12170083a Reviewed-on: https://go-review.googlesource.com/40670 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This is a more thorough and cleaner fix than doing dead code elimination separately during inlining, escape analysis, and export. Unfortunately, it does add another full walk of the AST. The performance impact is very small, but not non-zero. If a label or goto is present in the dead code, it is not eliminated. This restriction can be removed once label/goto checking occurs much earlier in the compiler. In practice, it probably doesn't matter much. Updates #19699 Fixes #19705 name old alloc/op new alloc/op delta Template 39.2MB ± 0% 39.3MB ± 0% +0.28% (p=0.008 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=1.000 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% -0.55% (p=0.008 n=5+5) SSA 1.25GB ± 0% 1.25GB ± 0% +0.02% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.3MB ± 0% -0.24% (p=0.032 n=5+5) GoParser 31.7MB ± 0% 31.8MB ± 0% +0.31% (p=0.008 n=5+5) Reflect 78.2MB ± 0% 78.3MB ± 0% ~ (p=0.421 n=5+5) Tar 26.6MB ± 0% 26.7MB ± 0% +0.21% (p=0.008 n=5+5) XML 42.2MB ± 0% 42.2MB ± 0% ~ (p=0.056 n=5+5) name old allocs/op new allocs/op delta Template 385k ± 0% 387k ± 0% +0.51% (p=0.016 n=5+5) Unicode 321k ± 0% 321k ± 0% ~ (p=1.000 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% ~ (p=1.000 n=5+5) SSA 9.71M ± 0% 9.72M ± 0% +0.10% (p=0.008 n=5+5) Flate 234k ± 1% 234k ± 1% ~ (p=0.690 n=5+5) GoParser 315k ± 0% 317k ± 0% +0.71% (p=0.008 n=5+5) Reflect 980k ± 0% 983k ± 0% +0.30% (p=0.032 n=5+5) Tar 251k ± 0% 252k ± 0% +0.55% (p=0.016 n=5+5) XML 392k ± 0% 393k ± 0% +0.30% (p=0.008 n=5+5) Change-Id: Ia10ff4bbf5c6eae782582cc9cbc9785494d4fb83 Reviewed-on: https://go-review.googlesource.com/38773 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
