- 29 Oct, 2015 12 commits
-
-
Michael Hudson-Doyle authored
On ppc64x, the thread pointer, held in R13, points 0x7000 bytes past where thread-local storage begins (presumably to maximize the amount of storage that can be accessed with a 16-bit signed displacement). The relocations used to indicate thread-local storage to the platform linker account for this, so to be able to support external linking we need to change things so the linker applies this offset instead of the runtime assembly. Change-Id: I2556c249ab2d802cae62c44b2b4c5b44787d7059 Reviewed-on: https://go-review.googlesource.com/14233Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Brad Fitzpatrick authored
The bug number was a typo, and I forgot to switch the implementation back to if statements after the change from Float64bits in the first patchset back to branching. if statements can currently be inlined, but switch cannot (#13071) Change-Id: I81d0cf64bda69186c3d747a07047f6a694f8fa70 Reviewed-on: https://go-review.googlesource.com/16446Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
And get rid of the stupid game of encoding the instruction in the addend. Change-Id: Ib4de7515196cbc1e63b4261b01931cf02a44c1e6 Reviewed-on: https://go-review.googlesource.com/14055Reviewed-by: Russ Cox <rsc@golang.org>
-
Taru Karttunen authored
Errors with http.Redirect and http.StatusOk seem to occur from time to time on the irc channel. This change adds documentation suggesting to use one of the 3xx codes and not StatusOk with Redirect. Change-Id: I6b900a8eb868265fbbb846ee6a53e426d90a727d Reviewed-on: https://go-review.googlesource.com/15980Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
The compiler can do a fine job, and can also inline it. From Jeremy Jackins's observation and rsc's recommendation in thread: "Pure Go math.Abs outperforms assembly version" https://groups.google.com/forum/#!topic/golang-dev/nP5mWvwAXZo Updates #13095 Change-Id: I3066f8eaa327bb403173b29791cc8661d7c0532c Reviewed-on: https://go-review.googlesource.com/16444Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: Ibddbbf6f4a5bd336a8b234d40fad0fcea574cd6e Reviewed-on: https://go-review.googlesource.com/13994Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
When dynamically linking, we want references to functions defined in this module to always be to the function object, not to the PLT. We force this by writing an additional local symbol for every global function symbol and making all relocations against the global symbol refer to this local symbol instead. This is approximately equivalent to the ELF linker -Bsymbolic-functions option, but that is buggy on several platforms. Change-Id: Ie6983eb4d1947f8543736fd349f9a90df3cce91a Reviewed-on: https://go-review.googlesource.com/16436Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David Crawshaw authored
Change-Id: Ic826dc25b5203b2e9fc253d6fe997e4b41de3789 Reviewed-on: https://go-review.googlesource.com/16453Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Burcu Dogan authored
os.Kill cannot be caught on Unix systems. The example gives the false impression that it can. Fixes #13080. Change-Id: I3b9e6f38a38f437a463c5b869ae84a0d3fd23f72 Reviewed-on: https://go-review.googlesource.com/16467Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Dominik Honnef authored
Change-Id: I657588ccc4a87e075d15acb9f4cd1e417bbd7960 Reviewed-on: https://go-review.googlesource.com/16421Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
This is needed to make external linking work. Change-Id: I4cf7edb4ea318849cab92a697952f8745eed40c4 Reviewed-on: https://go-review.googlesource.com/14237Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
In the same manner in which runtime/cgo is included on other architectures. Change-Id: I90a5ad8585248b2566d763d33994a600508d89cb Reviewed-on: https://go-review.googlesource.com/14221Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 28 Oct, 2015 14 commits
-
-
Michael Hudson-Doyle authored
Change-Id: I20840632771a250fb279df64d394135994482af8 Reviewed-on: https://go-review.googlesource.com/14186Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Ian Lance Taylor authored
Change-Id: Iffe27445e35ec071cf0920a05c81b8a97a3ed712 Reviewed-on: https://go-review.googlesource.com/16431Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
Change-Id: I7dab124842f5209097a8d5a802fcbdde650654fa Reviewed-on: https://go-review.googlesource.com/16395Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hyang-Ah Hana Kim authored
For golang/go#10743 golang/go#10807 Change-Id: I35dedb52e2b47fe7ffc655d01f22ac05fe830bde Reviewed-on: https://go-review.googlesource.com/16396Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Hyang-Ah Hana Kim authored
For golang/go#10743 Change-Id: Iec047821147a0e28edebf875fefe25993785702b Reviewed-on: https://go-review.googlesource.com/15994Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Hyang-Ah Hana Kim authored
Android linker does not handle TLS for us. We set up the TLS slot for g, as darwin/386,amd64 handle instead. This is disgusting and fragile. We will eventually fix this ugly hack by taking advantage of the recent TLS IE model implementation. (Instead of referencing an GOT entry, make the code sequence look into the TLS variable that holds the offset.) The TLS slot for g in android/amd64 assumes a fixed offset from %fs. See runtime/cgo/gcc_android_amd64.c for details. For golang/go#10743 Change-Id: I1a3fc207946c665515f79026a56ea19134ede2dd Reviewed-on: https://go-review.googlesource.com/15991Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: Iaf9159a68fa395245bc20ccb4a2a377f89371a7e Reviewed-on: https://go-review.googlesource.com/13996Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Michael Hudson-Doyle authored
Fixes #10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122 Reviewed-on: https://go-review.googlesource.com/13991Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Brad Fitzpatrick authored
Adds ReverseProxy.BufferPool for users with sensitive allocation requirements. Permits avoiding 32 KB of io.Copy garbage per request. Fixes #10277 Change-Id: I5dfd58fa70a363ead4be56405e507df90d871719 Reviewed-on: https://go-review.googlesource.com/9399Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
In the Go signal handler on Plan 9, when a signal with the _SigThrow flag is received, we call startpanic before printing the stack trace. The startpanic function calls systemstack which calls startpanic_m. In the startpanic_m function, we call allocmcache to allocate _g_.m.mcache. The problem is that allocmcache calls nextSample, which does a floating point operation to return a sampling point for heap profiling. However, Plan 9 doesn't support floating point in the signal handler. This change adds a new function nextSampleNoFP, only called when in the Plan 9 signal handler, which is similar to nextSample, but avoids floating point. Change-Id: Iaa30437aa0f7c8c84d40afbab7567ad3bd5ea2de Reviewed-on: https://go-review.googlesource.com/16307Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: Idc5c4a69919a8ed9d76d4a9cfd9827fb5c59dd11 Reviewed-on: https://go-review.googlesource.com/16389Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Nodir Turakulov authored
Change-Id: I8cc9783fd044bed48347824dcf973c61c78275a5 Reviewed-on: https://go-review.googlesource.com/15833Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Michael Hudson-Doyle authored
The dynamic linker on linux/386 stores the address of the vsyscall helper at a fixed offset from the %gs register on linux/386 for easy access from PIC code. Change-Id: I635305cfecceef2289985d62e676e16810ed6b94 Reviewed-on: https://go-review.googlesource.com/16346Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: If3417135ca474468a480b08cf46334fda28f79b4 Reviewed-on: https://go-review.googlesource.com/16345Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 27 Oct, 2015 4 commits
-
-
Brad Fitzpatrick authored
This part got dropped when we were debating between two solutions in https://golang.org/cl/15151 Fixes #13032 Change-Id: I820b94f6c0c102ccf9342abf957328ea01f49a26 Reviewed-on: https://go-review.googlesource.com/16313Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
kargakis authored
Change-Id: I86cdd5c1d7b6f76d3474d180e75ea0c732241080 Reviewed-on: https://go-review.googlesource.com/16309Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Hudson-Doyle authored
Nothing uses this. Change-Id: Ibc13066940bd2ea5c74d955a67f9dc531bef2758 Reviewed-on: https://go-review.googlesource.com/16344Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
arena_{start,used,end} are already uintptr, so no need to convert them to uintptr, much less to convert them to unsafe.Pointer and then to uintptr. No binary change to pkg/linux_amd64/runtime.a. Change-Id: Ia4232ed2a724c44fde7eba403c5fe8e6dccaa879 Reviewed-on: https://go-review.googlesource.com/16339Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
- 26 Oct, 2015 10 commits
-
-
Robert Griesemer authored
Change-Id: Ia34b6dd099d07d5e1d4bffe775a20fa92705fdb0 Reviewed-on: https://go-review.googlesource.com/16335 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Change-Id: I956e27fa07f16060b8f41b986d991c36557f7c12 Reviewed-on: https://go-review.googlesource.com/16332Reviewed-by: Keith Randall <khr@golang.org>
-
David du Colombier authored
There is no signal list on Plan 9, since notes are strings. However, some programs expect signals to be defined in the syscall package. Hence, we define a list of the most common notes. Updates #11975. Change-Id: I852e14fd98777c9595a406e04125be1cbebed0fb Reviewed-on: https://go-review.googlesource.com/16301Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
Implement an abort note on Plan 9, as an equivalent of the SIGABRT signal on other operating systems. Updates #11975. Change-Id: I010c9b10f2fbd2471aacd1d073368d975a2f0592 Reviewed-on: https://go-review.googlesource.com/16300Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
When a new tiny block is allocated because we're allocating an object that won't fit into the current block, mallocgc saves the new block if it has more space leftover than the old block. However, the logic for this was subtly broken in golang.org/cl/2814, resulting in never saving (or consequently reusing) a tiny block. Change-Id: Ib5f6769451fb82877ddeefe75dfe79ed4a04fd40 Reviewed-on: https://go-review.googlesource.com/16330 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Robert Griesemer authored
Necessary to ensure that subsequent tools can continue to find then end of the export data section simply by searching for "$$". Adjusted gcimporter used by go/types accordingly. Also, fixed a bug in gcimporter related to reading export data in debug format. Change-Id: Iaea4ed05edd8a5bab28ebe5b19a4740f5e537d35 Reviewed-on: https://go-review.googlesource.com/16283Reviewed-by: Chris Manghane <cmang@golang.org>
-
Austin Clements authored
Currently data and BSS root marking are each a single markroot job. This makes them difficult to load balance, which can draw out mark termination time if they are large. Fix this by splitting both in to 256K chunks. While we're putting in the infrastructure for dynamic roots, we also replace the fixed sharding of the span roots with sharding in to fixed sizes. In addition to helping balance root marking, this also paves the way to parallelizing concurrent scan and to letting assists help with root marking. Updates #10345. This fixes the data and BSS aspects of that bug; it does not partition scanning of large heap objects. This has negligible effect on either the go1 benchmarks or the garbage benchmark: name old time/op new time/op delta XBenchGarbage-12 4.90ms ± 1% 4.91ms ± 2% ~ (p=0.058 n=17+16) name old time/op new time/op delta BinaryTree17-12 3.11s ± 4% 3.12s ± 4% ~ (p=0.512 n=20+20) Fannkuch11-12 2.53s ± 2% 2.47s ± 2% -2.28% (p=0.000 n=20+18) FmtFprintfEmpty-12 49.1ns ± 1% 50.0ns ± 4% +1.68% (p=0.008 n=18+20) FmtFprintfString-12 170ns ± 0% 172ns ± 1% +1.05% (p=0.000 n=14+19) FmtFprintfInt-12 174ns ± 1% 162ns ± 1% -6.81% (p=0.000 n=18+17) FmtFprintfIntInt-12 284ns ± 1% 277ns ± 1% -2.42% (p=0.000 n=20+19) FmtFprintfPrefixedInt-12 252ns ± 1% 244ns ± 1% -2.84% (p=0.000 n=18+20) FmtFprintfFloat-12 317ns ± 0% 311ns ± 0% -1.95% (p=0.000 n=19+18) FmtManyArgs-12 1.08µs ± 1% 1.11µs ± 1% +3.43% (p=0.000 n=18+19) GobDecode-12 8.56ms ± 1% 8.61ms ± 1% +0.50% (p=0.020 n=20+20) GobEncode-12 6.58ms ± 1% 6.57ms ± 1% ~ (p=0.792 n=20+19) Gzip-12 317ms ± 3% 317ms ± 2% ~ (p=0.840 n=19+19) Gunzip-12 41.6ms ± 0% 41.6ms ± 0% +0.07% (p=0.027 n=18+15) HTTPClientServer-12 62.2µs ± 1% 62.3µs ± 1% ~ (p=0.283 n=19+20) JSONEncode-12 16.5ms ± 2% 16.5ms ± 1% ~ (p=0.857 n=20+19) JSONDecode-12 58.5ms ± 1% 61.3ms ± 1% +4.67% (p=0.000 n=18+17) Mandelbrot200-12 3.84ms ± 0% 3.84ms ± 0% ~ (p=0.259 n=17+17) GoParse-12 3.70ms ± 2% 3.74ms ± 2% +0.96% (p=0.009 n=19+20) RegexpMatchEasy0_32-12 100ns ± 1% 100ns ± 0% +0.31% (p=0.040 n=19+15) RegexpMatchEasy0_1K-12 340ns ± 1% 340ns ± 1% ~ (p=0.411 n=17+19) RegexpMatchEasy1_32-12 82.7ns ± 2% 82.3ns ± 1% ~ (p=0.456 n=20+19) RegexpMatchEasy1_1K-12 498ns ± 2% 495ns ± 0% ~ (p=0.108 n=19+17) RegexpMatchMedium_32-12 130ns ± 1% 130ns ± 2% ~ (p=0.405 n=18+19) RegexpMatchMedium_1K-12 39.4µs ± 2% 39.1µs ± 1% -0.64% (p=0.002 n=20+19) RegexpMatchHard_32-12 2.03µs ± 2% 2.02µs ± 0% ~ (p=0.561 n=20+17) RegexpMatchHard_1K-12 61.1µs ± 2% 60.8µs ± 1% ~ (p=0.615 n=19+18) Revcomp-12 532ms ± 2% 531ms ± 1% ~ (p=0.470 n=19+19) Template-12 68.5ms ± 1% 69.1ms ± 1% +0.87% (p=0.000 n=17+17) TimeParse-12 344ns ± 2% 344ns ± 1% +0.25% (p=0.032 n=19+18) TimeFormat-12 347ns ± 1% 362ns ± 1% +4.27% (p=0.000 n=17+19) [Geo mean] 62.3µs 62.3µs -0.04% name old speed new speed delta GobDecode-12 89.6MB/s ± 1% 89.2MB/s ± 1% -0.50% (p=0.019 n=20+20) GobEncode-12 117MB/s ± 1% 117MB/s ± 1% ~ (p=0.797 n=20+19) Gzip-12 61.3MB/s ± 3% 61.2MB/s ± 2% ~ (p=0.834 n=19+19) Gunzip-12 467MB/s ± 0% 466MB/s ± 0% -0.07% (p=0.027 n=18+15) JSONEncode-12 117MB/s ± 2% 117MB/s ± 1% ~ (p=0.851 n=20+19) JSONDecode-12 33.2MB/s ± 1% 31.7MB/s ± 1% -4.47% (p=0.000 n=18+17) GoParse-12 15.6MB/s ± 2% 15.5MB/s ± 2% -0.95% (p=0.008 n=19+20) RegexpMatchEasy0_32-12 321MB/s ± 2% 320MB/s ± 1% -0.57% (p=0.002 n=17+17) RegexpMatchEasy0_1K-12 3.01GB/s ± 1% 3.01GB/s ± 1% ~ (p=0.132 n=17+18) RegexpMatchEasy1_32-12 387MB/s ± 2% 389MB/s ± 1% ~ (p=0.423 n=20+19) RegexpMatchEasy1_1K-12 2.05GB/s ± 2% 2.06GB/s ± 0% ~ (p=0.129 n=19+17) RegexpMatchMedium_32-12 7.64MB/s ± 1% 7.66MB/s ± 1% ~ (p=0.258 n=18+19) RegexpMatchMedium_1K-12 26.0MB/s ± 2% 26.2MB/s ± 1% +0.64% (p=0.002 n=20+19) RegexpMatchHard_32-12 15.7MB/s ± 2% 15.8MB/s ± 1% ~ (p=0.510 n=20+17) RegexpMatchHard_1K-12 16.8MB/s ± 2% 16.8MB/s ± 1% ~ (p=0.603 n=19+18) Revcomp-12 477MB/s ± 2% 479MB/s ± 1% ~ (p=0.470 n=19+19) Template-12 28.3MB/s ± 1% 28.1MB/s ± 1% -0.85% (p=0.000 n=17+17) [Geo mean] 100MB/s 100MB/s -0.26% Change-Id: Ib0bfe0145675ce88c5a8791752f7486ac98805b4 Reviewed-on: https://go-review.googlesource.com/16043Reviewed-by: Rick Hudson <rlh@golang.org>
-
David Crawshaw authored
It's the only ARM version we have ever supported on android. (Not setting it caused some builder timeouts.) Change-Id: I26061434252ff2a236bb31d95787a1c582d24b3f Reviewed-on: https://go-review.googlesource.com/16295Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
David Crawshaw authored
I went looking for an arm system whose stacks are by default smaller than 64KB. In fact the smallest common linux target I could find was Android, which like iOS uses 1MB stacks. Fixes #11873 Change-Id: Ieeb66ad095b3da18d47ba21360ea75152a4107c6 Reviewed-on: https://go-review.googlesource.com/14602Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Minux Ma <minux@golang.org>
-
Marcel van Lohuizen authored
gc will need to be rebuild. Package that assume f.PkgPath != nil means a field is unexported and must be ignored must be revised to check for f.PkgPath != nil && !f.Anonymous, so that they do try to walk into the embedded fields to look for exported fields contained within. Closes #12367, fixes #7363, fixes #11007, and fixes #7247. Change-Id: I16402ee21ccfede80f277f84b3995cf26e97433d Reviewed-on: https://go-review.googlesource.com/14085Reviewed-by: Russ Cox <rsc@golang.org>
-