- 25 Oct, 2016 40 commits
-
-
Matthew Dempsky authored
Change-Id: I7306d28930dc4538a3bee31ff5d22f3f40681ec5 Reviewed-on: https://go-review.googlesource.com/32020 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Now that sweeping and span marking use the sweep list, there's no need for the work.spans snapshot of the allspans list. This change eliminates the few remaining uses of it, which are either dead code or can use allspans directly, and removes work.spans and its support functions. Change-Id: Id5388b42b1e68e8baee853d8eafb8bb4ff95bb43 Reviewed-on: https://go-review.googlesource.com/30537 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 markrootSpans iterates over all spans ever allocated to find the in-use spans. Since we now have a list of in-use spans, change it to iterate over that instead. This, combined with the previous change, fixes #9265. Before these two changes, blowing up the heap to 8GB and then shrinking it to a 0MB live set caused the small-heap portion of the test to run 60x slower than without the initial blowup. With these two changes, the time is indistinguishable. No significant effect on other benchmarks. Change-Id: I4a27e533efecfb5d18cba3a87c0181a81d0ddc1e Reviewed-on: https://go-review.googlesource.com/30536 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 sweeping walks the list of all spans, which means the work in sweeping is proportional to the maximum number of spans ever used. If the heap was once large but is now small, this causes an amortization failure: on a small heap, GCs happen frequently, but a full sweep still has to happen in each GC cycle, which means we spent a lot of time in sweeping. Fix this by creating a separate list consisting of just the in-use spans to be swept, so sweeping is proportional to the number of in-use spans (which is proportional to the live heap). Specifically, we create two lists: a list of unswept in-use spans and a list of swept in-use spans. At the start of the sweep cycle, the swept list becomes the unswept list and the new swept list is empty. Allocating a new in-use span adds it to the swept list. Sweeping moves spans from the unswept list to the swept list. This fixes the amortization problem because a shrinking heap moves spans off the unswept list without adding them to the swept list, reducing the time required by the next sweep cycle. Updates #9265. This fix eliminates almost all of the time spent in sweepone; however, markrootSpans has essentially the same bug, so now the test program from this issue spends all of its time in markrootSpans. No significant effect on other benchmarks. Change-Id: Ib382e82790aad907da1c127e62b3ab45d7a4ac1e Reviewed-on: https://go-review.googlesource.com/30535 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Change-Id: I4b8a6f5d9bc5aba16026d17f99f3512dacde8d2d Reviewed-on: https://go-review.googlesource.com/30534 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 we set the len and cap of h.spans to the full reserved region of the address space and track the actual mapped region separately in h.spans_mapped. Since we have both the len and cap at our disposal, change things so len(h.spans) tracks how much of the spans array is mapped and eliminate h.spans_mapped. This simplifies mheap and means we'll get nice "index out of bounds" exceptions if we do try to go off the end of the spans rather than a SIGSEGV. Change-Id: I8ed9a1a9a844d90e9fd2e269add4704623dbdfe6 Reviewed-on: https://go-review.googlesource.com/30533 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Like h_allspans and mheap_.allspans, these were two ways of referring to the spans array from when the runtime was split between C and Go. Clean this up by making mheap_.spans a slice and eliminating h_spans. Change-Id: I3aa7038d53c3a4252050aa33e468c48dfed0b70e Reviewed-on: https://go-review.googlesource.com/30532 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
This was necessary in the C days when allspans was an mspan**, but now that allspans is a Go slice, this is redundant with len(allspans) and we can use range loops over allspans. Change-Id: Ie1dc39611e574e29a896e01690582933f4c5be7e Reviewed-on: https://go-review.googlesource.com/30531 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
These are two ways to refer to the allspans array that hark back to when the runtime was split between C and Go. Clean this up by making mheap_.allspans a slice and eliminating h_allspans. Change-Id: Ic9360d040cf3eb590b5dfbab0b82e8ace8525610 Reviewed-on: https://go-review.googlesource.com/30530 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Matthew Dempsky authored
Change-Id: I3c784986755cfbbe1b8eb8da4d64227bd109a3b0 Reviewed-on: https://go-review.googlesource.com/27203 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
David du Colombier authored
Generated from go vet. Change-Id: Ie775c29b505166e0bd511826ef20eeb153a0424c Reviewed-on: https://go-review.googlesource.com/32071Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
Generated from go vet. Change-Id: I2620e5544be46485a876c7dce26b0592bf5a4101 Reviewed-on: https://go-review.googlesource.com/32070Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
When the compiler insert write barriers, the frontend makes conservative decisions at an early stage. This may have false positives which result in write barriers for stack writes. A new phase, writebarrier, is added to the SSA backend, to delay the decision and eliminate false positives. The frontend still makes conservative decisions. When building SSA, instead of emitting runtime calls directly, it emits WB ops (StoreWB, MoveWB, etc.), which will be expanded to branches and runtime calls in writebarrier phase. Writes to static locations on stack are detected and write barriers are removed. All write barriers of stack writes found by the script from issue #17330 are eliminated (except two false positives). Fixes #17330. Change-Id: I9bd66333da9d0ceb64dcaa3c6f33502798d1a0f8 Reviewed-on: https://go-review.googlesource.com/31131Reviewed-by:
Austin Clements <austin@google.com> Reviewed-by:
David Chase <drchase@google.com> Reviewed-by:
Keith Randall <khr@golang.org>
-
Cherry Zhang authored
The runtime traceback code assumes non-empty frame has link link register saved on LR architectures. Make sure it is so in the assember. Also make sure that LR is stored before update SP, so the traceback code will not see a half-updated stack frame if a signal comes during the execution of function prologue. Fixes #17381. Change-Id: I668b04501999b7f9b080275a2d1f8a57029cbbb3 Reviewed-on: https://go-review.googlesource.com/31760Reviewed-by:
Michael Munday <munday@ca.ibm.com>
-
Tom Bergan authored
This interface will be implemented by golang.org/x/net/http2 in https://go-review.googlesource.com/c/29439/. Updates golang/go#13443 Change-Id: Ib6bdd403b0878cfe36fa9875c07c2c7239232556 Reviewed-on: https://go-review.googlesource.com/32012 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Lynn Boger authored
Update the ppc64x disassembly code for use by objdump from golang.org/x/arch/ppc64/ppc64asm commit fcea5ea. Enable the objdump testcase for external linking on ppc64le make a minor fix to the expected output. Fixes #17447 Change-Id: I769cc7f8bfade594690a476dfe77ab33677ac03b Reviewed-on: https://go-review.googlesource.com/32015 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #17148. Change-Id: I4c66aa0733c249ee6019d1c4e802a7e30457d4b6 Reviewed-on: https://go-review.googlesource.com/32030 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Ian Lance Taylor authored
The Dragonfly libc returns a non-zero value for malloc(-1). Fixes #17585. Change-Id: Icfe68011ccbc75c676273ee3c3efdf24a520a004 Reviewed-on: https://go-review.googlesource.com/32050 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
shaharko authored
Reduces the size of LSym struct. On 32bit: before 84 after 76 On 64bit: before 136 after 128 name old time/op new time/op delta Template 182ms ± 3% 182ms ± 3% ~ (p=0.607 n=19+20) Unicode 93.5ms ± 4% 94.2ms ± 3% ~ (p=0.141 n=20+19) GoTypes 608ms ± 1% 605ms ± 2% ~ (p=0.056 n=20+20) name old user-ns/op new user-ns/op delta Template 249M ± 7% 249M ± 4% ~ (p=0.605 n=18+19) Unicode 149M ±14% 151M ± 5% ~ (p=0.724 n=20+17) GoTypes 855M ± 4% 853M ± 3% ~ (p=0.537 n=19+19) name old alloc/op new alloc/op delta Template 40.3MB ± 0% 40.3MB ± 0% -0.11% (p=0.000 n=19+20) Unicode 33.8MB ± 0% 33.8MB ± 0% -0.08% (p=0.000 n=20+20) GoTypes 119MB ± 0% 119MB ± 0% -0.10% (p=0.000 n=19+20) name old allocs/op new allocs/op delta Template 383k ± 0% 383k ± 0% ~ (p=0.703 n=20+20) Unicode 317k ± 0% 317k ± 0% ~ (p=0.982 n=19+18) GoTypes 1.14M ± 0% 1.14M ± 0% ~ (p=0.086 n=20+20) Change-Id: Id6ba0db3ecc4503a4e9af3ed0d5884d4366e8bf9 Reviewed-on: https://go-review.googlesource.com/31870Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: Shahar Kohanim <skohanim@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Rob Pike authored
For historical reasons, the go/doc package does not include the methods within an interface as part of the documented methods for that type. Thus, go doc ast.Node.Pos gives an incorrect and confusing error message: doc: no method Node.Pos in package go/ast This CL does some dirty work to dig down to the methods so interface methods now present their documentation: % go doc ast.node.pos func Pos() token.Pos // position of first character belonging to the node % It must largely sidestep the doc package to do this, which is a shame. Perhaps things will improve there one day. The change does not handle embeddings, and in principle the same approach could be done for struct fields, but that is also not here yet. But this CL fixes the thing that was bugging me. Change-Id: Ic10a91936da96f54ee0b2f4a4fe4a8c9b93a5b4a Reviewed-on: https://go-review.googlesource.com/31852Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Josh Bleecher Snyder authored
CL 31330 added more envvars to "go env". This CL brings them to "go bug" as well. Change-Id: Iae122072c8178007eda8b765aaa3f38c3c6e39a0 Reviewed-on: https://go-review.googlesource.com/32011 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
shaharko authored
Instead of generating typelink symbols in the compiler mark types that should have typelinks with a flag. The linker detects this flag and adds the marked types to the typelink table. name old s/op new s/op delta LinkCmdCompile 0.27 ± 6% 0.25 ± 6% -6.93% (p=0.000 n=97+98) LinkCmdGo 0.30 ± 5% 0.29 ±10% -4.22% (p=0.000 n=97+99) name old MaxRSS new MaxRSS delta LinkCmdCompile 112k ± 3% 106k ± 2% -4.85% (p=0.000 n=100+100) LinkCmdGo 107k ± 3% 103k ± 3% -3.00% (p=0.000 n=100+100) Change-Id: Ic95dd4b0101e90c1fa262c9c6c03a2028d6b3623 Reviewed-on: https://go-review.googlesource.com/31772 Run-TryBot: Shahar Kohanim <skohanim@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Mohit Agarwal authored
The condition to determine if any further iterations are needed is evaluated to false in case it encounters a NaN. Instead, flip the condition to keep looping until the factor is greater than the machine roundoff error. Updates #17577 Change-Id: I058abe73fcd49d3ae4e2f7b33020437cc8f290c3 Reviewed-on: https://go-review.googlesource.com/31952Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
In sinit.go, gdata can already handle strings and complex, so no reason to handle them separately. In obj.go, inline gdatastring and gdatacomplex into gdata, since it's the only caller. Allows extracting out the common Linksym calls. Passes toolstash -cmp. Change-Id: I3cb18d9b4206a8a269c36e0d30a345d8e6caba1f Reviewed-on: https://go-review.googlesource.com/31498 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Matthew Dempsky authored
Fixes #17584. Change-Id: I3af31cc1f2e9c906f3b73e77f3b092624ba78fbe Reviewed-on: https://go-review.googlesource.com/31939 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
David Chase authored
Bug 15141 was apparently fixed by some other change to the compiler (this is plausible, it was a weird bug dependent on a particular way of returning a large named array result), add the test to ensure that it stays fixed. Updates #15141. Change-Id: I3d6937556413fab1af31c5a1940e6931563ce2f3 Reviewed-on: https://go-review.googlesource.com/31972 Run-TryBot: David Chase <drchase@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
No functional changes. Change-Id: I0842b2560f4296abfc453410fdd79514132cab83 Reviewed-on: https://go-review.googlesource.com/31935 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
It no longer exists as of CL 31010. Change-Id: Idd61f392544cad8b3f3f8d984dc5c953b473e2e5 Reviewed-on: https://go-review.googlesource.com/31934 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Lynn Boger authored
Some original shift opcodes for ppc64x expected an operand to be a mask instead of a shift count, preventing some valid shift counts from being written. This adds new opcodes for shifts where needed, using mnemonics that match the ppc64 asm and allowing the assembler to accept the full set of valid shift counts. Fixes #15016 Change-Id: Id573489f852038d06def279c13fd0523736878a7 Reviewed-on: https://go-review.googlesource.com/31853 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by:
David Chase <drchase@google.com>
-
Josh Bleecher Snyder authored
Change-Id: Ie505b5d8cdfe4ffda71f909d6f81603b6d752eed Reviewed-on: https://go-review.googlesource.com/31937 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
Change-Id: Ia499125714e272af87562de5e5d23e68a112df58 Reviewed-on: https://go-review.googlesource.com/31938 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
While we're here, use test[%d] in place of #%d. Change-Id: Ie30afcab9673e78d3ea7ca80f5e662fbea897488 Reviewed-on: https://go-review.googlesource.com/31936 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
Introduced in CLs 29380 and 30011. Change-Id: I3d3641e8748ce0adb57b087a1fcd62f295ade665 Reviewed-on: https://go-review.googlesource.com/31933 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Russ Cox authored
Fixes #16811. Change-Id: I7d018015f691838482ccf845d621209b96935ba4 Reviewed-on: https://go-review.googlesource.com/31657 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Quentin Smith <quentin@golang.org>
-
Michael Munday authored
These are emulated by the assembler and we don't need them. Change-Id: I2b07c5315a5b642fdb5e50b468453260ae121164 Reviewed-on: https://go-review.googlesource.com/31758Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Munday authored
Implements the following intrinsics on s390x: - AtomicAdd{32,64} - AtomicCompareAndSwap{32,64} - AtomicExchange{32,64} - AtomicLoad{32,64,Ptr} - AtomicStore{32,64,PtrNoWB} I haven't added rules for And8 or Or8 yet. Change-Id: I647af023a8e513718e90e98a60191e7af6167314 Reviewed-on: https://go-review.googlesource.com/31614 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Martin Möhrmann authored
Apply the optimizations added to color conversion functions in https://go-review.googlesource.com/#/c/21910/ to the RGBA methods. YCbCrToRGBA/0-4 6.32ns ± 3% 6.58ns ± 2% +4.15% (p=0.000 n=20+19) YCbCrToRGBA/128-4 8.02ns ± 2% 5.89ns ± 2% -26.57% (p=0.000 n=20+19) YCbCrToRGBA/255-4 8.06ns ± 2% 6.59ns ± 3% -18.18% (p=0.000 n=20+20) NYCbCrAToRGBA/0-4 8.71ns ± 2% 8.78ns ± 2% +0.86% (p=0.036 n=19+20) NYCbCrAToRGBA/128-4 10.3ns ± 4% 7.9ns ± 2% -23.44% (p=0.000 n=20+20) NYCbCrAToRGBA/255-4 9.64ns ± 2% 8.79ns ± 3% -8.80% (p=0.000 n=20+20) Fixes: #15260 Change-Id: I225efdf74603e8d2b4f063054f7baee7a5029de6 Reviewed-on: https://go-review.googlesource.com/31773 Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
shaharko authored
name old s/op new s/op delta LinkCmdGo 0.29 ± 5% 0.29 ± 8% -2.60% (p=0.000 n=97+98) name old MaxRSS new MaxRSS delta LinkCmdGo 106k ± 4% 105k ± 3% -1.00% (p=0.000 n=100+99) Change-Id: I75a1c3b24ea711a15a5d2eae026b70b97ee7bad4 Reviewed-on: https://go-review.googlesource.com/31030 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
shaharko authored
Before go supported buildmode=shared ·f symbols used to be defined only when they were used. In order to solve #11480 the strategy was changed to have these symbols defined on declaration which is less efficient and generates many unneeded symbols. With this change the best strategy is chosen for each situation, improving static linking time: name old s/op new s/op delta LinkCmdCompile 0.27 ± 5% 0.25 ± 6% -8.22% (p=0.000 n=98+96) LinkCmdGo 0.30 ± 6% 0.29 ± 8% -5.03% (p=0.000 n=95+99) name old MaxRSS new MaxRSS delta LinkCmdCompile 107k ± 2% 98k ± 3% -8.32% (p=0.000 n=99+100) LinkCmdGo 106k ± 3% 104k ± 3% -1.94% (p=0.000 n=99+100) Change-Id: I965eeee30541e724fd363804adcd6fda10f965a4 Reviewed-on: https://go-review.googlesource.com/31031Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Paul Marks authored
In general, these functions cannot behave correctly when given a hostname, because a hostname may represent multiple IP addresses, and first(isIPv4) chooses at most one. Updates #9334 Change-Id: Icfb629f84af4d976476385a3071270253c0000b1 Reviewed-on: https://go-review.googlesource.com/31931Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-