An error occurred fetching the project authors.
- 17 Oct, 2015 1 commit
-
-
Michael Hudson-Doyle authored
Go cannot allow lazy PLT resolution when calling between Go functions because the lazy resolution can use more stack than is available. Lazy resolution is disabled by passing -z now to the system linker, but unfortunately was only passed when linking to a Go shared library. That sounds fine, but the shared library containing the runtime is not linked to any other Go shared library but calls main.init and main.main via a PLT, and before this fix this did use lazy resolution. (For some reason this never caused a problem on intel, but it breaks on ppc64le). Fortunately the fix is very simple: always pass -z now to the system linker when dynamically linking Go. Change-Id: I7806d40aac80dcd1e56b95864d1cfeb1c42614e2 Reviewed-on: https://go-review.googlesource.com/15870Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 08 Oct, 2015 2 commits
-
-
Ian Lance Taylor authored
Go shared libraries do not support dlclose, and there is no likelihood that they will suppose dlclose in the future. Set the DF_1_NODELETE flag to tell the dynamic linker to not attempt to remove them from memory. This makes the shared library act as though every call to dlopen passed the RTLD_NODELETE flag. Fixes #12582. Update #11100. Update #12873. Change-Id: Id4b6e90a1b54e2e6fc8355b5fb22c5978fc762b4 Reviewed-on: https://go-review.googlesource.com/15605Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Michael Hudson-Doyle authored
It's particularly nice to get rid of the android special cases in the linker. Change-Id: I516363af7ce8a6b2f196fe49cb8887ac787a6dad Reviewed-on: https://go-review.googlesource.com/14197 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 16 Sep, 2015 1 commit
-
-
Michael Hudson-Doyle authored
Not sure how I managed to do this, or get it past review. Change-Id: I141b97ef8e09dcc9c910c45493a584a3dced2b28 Reviewed-on: https://go-review.googlesource.com/14634Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 08 Sep, 2015 2 commits
-
-
Michael Hudson-Doyle authored
Currently Go produces shared libraries that cannot be shared between processes because they have relocations against the text segment (not text section). This fixes this by moving some data to sections with magic names recognized by the static linker. The change in genasmsym to add STYPELINK to the switch should fix things on darwin/arm64. Fixes #10914 Updates #9210 Change-Id: Iab4a6678dd04cec6114e683caac5cf31b1063309 Reviewed-on: https://go-review.googlesource.com/14306 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I88fa0cc245a2141af04acced8716e08b1133abd1 Reviewed-on: https://go-review.googlesource.com/14350Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 04 Sep, 2015 3 commits
-
-
Dave Cheney authored
Revert "cmd/internal/ld: put read-only relocated data into .data.rel.ro when making a shared object" This reverts commit 2c2cbb69. Broke darwin/arm64 Change-Id: Ibd2dea475d6ce6a8b4b40e2da19a83fc0514025d Reviewed-on: https://go-review.googlesource.com/14301Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Currently Go produces shared libraries that cannot be shared between processes because they have relocations against the text segment (not text section). This fixes this by moving some data to sections with magic names recognized by the static linker. Fixes #10914 Updates #9210 Change-Id: I7178daadc0ae87953d5a084aa3d580f4e3b46d47 Reviewed-on: https://go-review.googlesource.com/10300 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
And do it properly so freebsd and nacl still work. Change-Id: I6f9f30e93ceae6dee59215ed608c6a158bdbdbb0 Reviewed-on: https://go-review.googlesource.com/14280 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 03 Sep, 2015 2 commits
-
-
Michael Hudson-Doyle authored
This reverts commit bf99d8f8. Change-Id: Id4374ed35802cfbfe11e015ccd9526d3497dc8cc Reviewed-on: https://go-review.googlesource.com/14239Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Michael Hudson-Doyle authored
Change-Id: Ia18984343ca4ced3671d967ff9a5b0e32874430c Reviewed-on: https://go-review.googlesource.com/14220Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 01 Sep, 2015 1 commit
-
-
Michael Hudson-Doyle authored
Change-Id: I125a12a2cb7e792f357e4d841f55c0bed2971dce Reviewed-on: https://go-review.googlesource.com/14140 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
- 25 Aug, 2015 1 commit
-
-
Michael Hudson-Doyle authored
This was always a bit confusing, but it also fixes a problem: runtime.firstmoduledata was always overridden in the linker to be a local symbol but cmd/internal/obj had already rewritten code accessing it to access it via the GOT. This works on amd64, but causes link failures on other platforms (e.g. arm64). Change-Id: I9b8153af74b4d0f092211d63a000d15818f39773 Reviewed-on: https://go-review.googlesource.com/13786Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 29 Jul, 2015 1 commit
-
-
Russ Cox authored
The nosplit stack overflow checks were confused about morestack. The comment about not having correct SP information at the call to morestack was true, but that was a real bug, not something to work around. I fixed that problem in CL 12144. With that fixed, no need to special-case morestack in the way done here. This cleanup and simplification of the code was the first step to fixing a bug that happened when I started working on the arm64 frame size adjustments, but the cleanup was sufficient to make the bug go away. For #9880. Change-Id: I16b69a5c16b6b8cb4090295d3029c42d606e3b9b Reviewed-on: https://go-review.googlesource.com/12846Reviewed-by:
Austin Clements <austin@google.com>
-
- 23 Jul, 2015 2 commits
-
-
Ian Lance Taylor authored
On Windows, gcc -o foo will generate foo.exe. Prevent that from happening by adding a final '.' if necessary so that GCC thinks that the file already has an extension. Also remove the initial output file when doing an external link, and use mayberemoveoutfile, not os.Remove, when building an archive (otherwise we will do the wrong thing for -buildmode=c-archive -o /dev/null). I didn't add a test, as it requires using cgo and -o on Windows. Fixes #11725. Change-Id: I6ea12437bb6b4b9b8ee5c3b52d83509fa2437b2d Reviewed-on: https://go-review.googlesource.com/12243Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #11681. Change-Id: I679d71ed25ac585af7d43611be01c1a0c4807871 Reviewed-on: https://go-review.googlesource.com/12554 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 22 Jul, 2015 1 commit
-
-
Russ Cox authored
Same as we do for string symbols. Fixes #11583. Change-Id: Ia9264f6faf486697d987051b7f9851d37d8ad381 Reviewed-on: https://go-review.googlesource.com/12531Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 21 Jul, 2015 1 commit
-
-
Ian Lance Taylor authored
Fixes #10607. Change-Id: Ib294cf65b07103b60f62b86b21ff2d07b25136fe Reviewed-on: https://go-review.googlesource.com/12242Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 29 Jun, 2015 1 commit
-
-
Russ Cox authored
This code used to only be run for ELF, with the predictable result that using -s with external linking broke on Windows and OS X. Moving it here should fix Windows and does fix OS X. CL 10835 also claims to fix the crash on Windows. I don't know whether it does so correctly, but regardless, this CL should make that one a no-op. Fixes #10254. Change-Id: I2e7b45ab0c28568ddbb1b50581dcc157ae0e7ffe Reviewed-on: https://go-review.googlesource.com/11695Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
- 19 Jun, 2015 1 commit
-
-
Srdjan Petrovic authored
All of the heavy-lifting was done by minux@, with his external-linking support for darwin/arm64: golang.org/cl/8781 Change-Id: I7c9fbc19246f418c065c92fb2c13c00026ff0f82 Reviewed-on: https://go-review.googlesource.com/11127 Run-TryBot: Srdjan Petrovic <spetrovic@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 16 Jun, 2015 1 commit
-
-
Michael Hudson-Doyle authored
This makes the behaviour match what happens when duplicate symbols are read from regular object files and fixes errors about cgoAlwaysFalse when linking an executable that uses cgo against a shared library. Change-Id: Ibb8cd8fe3f7813cde504b7483f1e857868d7e063 Reviewed-on: https://go-review.googlesource.com/11117Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 09 Jun, 2015 1 commit
-
-
Hyang-Ah (Hana) Kim authored
Change-Id: If11621985c0a5a1f2133cdc974f37fd944b93e5e Reviewed-on: https://go-review.googlesource.com/10808 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 05 Jun, 2015 2 commits
-
-
Russ Cox authored
Also fix the interaction between -buildmode and -shared. It's okay for -shared to change the default build mode, but it's not okay for it to silently override an explicit -buildmode=exe. Change-Id: Id40f93d140cddf75b19e262b3ba4856ee09a07ba Reviewed-on: https://go-review.googlesource.com/10315Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Russ Cox authored
Change-Id: I3c9b05879fe0b6e94b63e9b65e4411ba2a917134 Reviewed-on: https://go-review.googlesource.com/10705Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 04 Jun, 2015 1 commit
-
-
Josh Bleecher Snyder authored
stkcheck is flow-insensitive: It processes calls in PC order. Since morestack was always the first call in a function, it was a safe, conservative approximation to simply adjust stack space as we went, recognizing morestack when it showed up. Subsequent CLS will rearrange the function prologue; morestack may no longer be the first call in a function. Introducing flow-sensitivity to stkcheck would allow this, and possibly allow a smaller stackguard. It is also a high risk change and possibly expensive. Instead, assume that all calls to morestack occur as part of the function prologue, no matter where they are located in the program text. Updates #10587. Change-Id: I4dcdd4256a980fc4bc433a68a10989ff57f7034f Reviewed-on: https://go-review.googlesource.com/10496 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 28 May, 2015 1 commit
-
-
Ryan Brown authored
Change-Id: I3a6df0a76d57db7cb6910f4179a6ce380f219a37 Reviewed-on: https://go-review.googlesource.com/10442Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 27 May, 2015 4 commits
-
-
Michael Hudson-Doyle authored
We already read the address of a gcmask/gcprog out of the type data, but I didn't know how many bytes to read. But it turns out that it's easy to calculate, so change to do that. This means that we no longer depend on the local symbols being present, allowing me to strip the shared libraries for distribution and make them a lot smaller. As a bonus, this makes LSym another 24 bytes smaller, down to 296 bytes now. Change-Id: I379d359e28d63afae6753efd23efdf1fbb716992 Reviewed-on: https://go-review.googlesource.com/10377Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
The motivation for this is the innocuous looking test case that is added. This creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem comes from the fact that a function from libdep.so gets inlined all the way into exe. This (unsurprisingly) means that the object file for exe references symbols from libdep.so, which means that -ldep needs to be passed when linking exe and it isn't. The fix is simply to pass it -- there is no harm in passing it when it's not needed. The thing is, it's not clear at all in the current code to see how the linker can know that libdep2 is linked against libdep. It could look through the DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it feels better to be explicit. So this adds another SHT_NOTE section that lists the shared libraries a shared library was linked against, and makes sure the complete set of depended upon shared libraries is passed to the external linker. Change-Id: I79aa6f98b4db4721d657a7eb7b7f062269bf49e2 Reviewed-on: https://go-review.googlesource.com/10376Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
This makes for a more stable API for tools (including cmd/link itself) to extract the abi hash from a shared library and makes it possible at all for a library that has had the local symbol table removed. The existing note-writing code only supports writing notes into the very start of the object file so they are easy to find in core dumps. This doesn't apply to the "go" notes and means that all notes have to fit into a fixed size budget. That's annoying now we have more notes (and the next CL will add another one) so this does a little bit of work to make adding notes that do not have to go at the start of the file easier and moves the writing of the package list note over to that mechanism, which lets me revert a hack that increased the size budget mentioned above for -buildmode=shared builds. Change-Id: I6077a68d395c8a2bc43dec8506e73c71ef77d9b9 Reviewed-on: https://go-review.googlesource.com/10375Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
The LSym.Section and Section.Elfsect fields were defined as interface{} but always had the same concrete type (*Section and *ElfShdr respectively) so just define them with that type. Reduces size of LSym from 328 to 320 bytes and reduces best-of-10 maxresident size from 246028k to 238036k when linking libstd.so. Change-Id: Ie7112c53e4c2c7ce5fe233b81372aa5633f572e8 Reviewed-on: https://go-review.googlesource.com/10410Reviewed-by:
Minux Ma <minux@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 26 May, 2015 1 commit
-
-
Ian Lance Taylor authored
It can be useful when debugging to be able to see what the external linker is doing even when it succeeds. In particular this permits passing -v to the external linker to see precisely what it is doing. Change-Id: Ifed441912d97bbebea20303fdb899e140b380215 Reviewed-on: https://go-review.googlesource.com/10363Reviewed-by:
Minux Ma <minux@golang.org>
-
- 21 May, 2015 3 commits
-
-
Russ Cox authored
This CL removes the remaining visible uses of the "architecture letter" concept. (They are no longer in tool names nor in source directory names.) Because the architecture letter concept is now gone, delete GOCHAR from "go env" output, and change go/build.ArchChar to return an error always. The architecture letter is still used in the compiler and linker sources as a clumsy architecture enumeration, but that use is not visible to Go users and can be cleaned up separately. Change-Id: I4d97a38f372003fb610c9c5241bea440d9dbeb8d Reviewed-on: https://go-review.googlesource.com/10289Reviewed-by:
Rob Pike <r@golang.org>
-
Russ Cox authored
Trivial merging of 5g, 6g, ... into go tool compile, and similarlly 5l, 6l, ... into go tool link. The files compile/main.go and link/main.go are new. Everything else in those directories is a move followed by change of imports and package name. This CL breaks the build. Manual fixups are in the next CL. See golang-dev thread titled "go tool compile, etc" for background. Change-Id: Id35ff5a5859ad9037c61275d637b1bd51df6828b Reviewed-on: https://go-review.googlesource.com/10287Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
Rob Pike <r@golang.org>
-
Ryan Brown authored
Fixes #8973 Change-Id: I746fae430db6d8f9ebd33586b8cffcb31d688cc8 Reviewed-on: https://go-review.googlesource.com/10284 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 19 May, 2015 2 commits
-
-
Josh Bleecher Snyder authored
This reverts commit 8b83306c. Change-Id: I3fb998bdf11eceef13e3997e336d86e7c5d47a60 Reviewed-on: https://go-review.googlesource.com/10254Reviewed-by:
Minux Ma <minux@golang.org>
-
Ryan Brown authored
Fixes #8973 Change-Id: Idd53fc6d9e6971ae31ed72a3df3cfdce0bfbc1fd Reviewed-on: https://go-review.googlesource.com/8661Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
-
- 16 May, 2015 1 commit
-
-
Russ Cox authored
Small types record the location of pointers in their memory layout by using a simple bitmap. In Go 1.4 the bitmap held 4-bit entries, and in Go 1.5 the bitmap holds 1-bit entries, but in both cases using a bitmap for a large type containing arrays does not make sense: if someone refers to the type [1<<28]*byte in a program in such a way that the type information makes it into the binary, it would be a waste of space to write a 128 MB (for 4-bit entries) or even 32 MB (for 1-bit entries) bitmap full of 1s into the binary or even to keep one in memory during the execution of the program. For large types containing arrays, it is much more compact to describe the locations of pointers using a notation that can express repetition than to lay out a bitmap of pointers. Go 1.4 included such a notation, called ``GC programs'' but it was complex, required recursion during decoding, and was generally slow. Dmitriy measured the execution of these programs writing directly to the heap bitmap as being 7x slower than copying from a preunrolled 4-bit mask (and frankly that code was not terribly fast either). For some tests, unrollgcprog1 was seen costing as much as 3x more than the rest of malloc combined. This CL introduces a different form for the GC programs. They use a simple Lempel-Ziv-style encoding of the 1-bit pointer information, in which the only operations are (1) emit the following n bits and (2) repeat the last n bits c more times. This encoding can be generated directly from the Go type information (using repetition only for arrays or large runs of non-pointer data) and it can be decoded very efficiently. In particular the decoding requires little state and no recursion, so that the entire decoding can run without any memory accesses other than the reads of the encoding and the writes of the decoded form to the heap bitmap. For recursive types like arrays of arrays of arrays, the inner instructions are only executed once, not n times, so that large repetitions run at full speed. (In contrast, large repetitions in the old programs repeated the individual bit-level layout of the inner data over and over.) The result is as much as 25x faster decoding compared to the old form. Because the old decoder was so slow, Go 1.4 had three (or so) cases for how to set the heap bitmap bits for an allocation of a given type: (1) If the type had an even number of words up to 32 words, then the 4-bit pointer mask for the type fit in no more than 16 bytes; store the 4-bit pointer mask directly in the binary and copy from it. (1b) If the type had an odd number of words up to 15 words, then the 4-bit pointer mask for the type, doubled to end on a byte boundary, fit in no more than 16 bytes; store that doubled mask directly in the binary and copy from it. (2) If the type had an even number of words up to 128 words, or an odd number of words up to 63 words (again due to doubling), then the 4-bit pointer mask would fit in a 64-byte unrolled mask. Store a GC program in the binary, but leave space in the BSS for the unrolled mask. Execute the GC program to construct the mask the first time it is needed, and thereafter copy from the mask. (3) Otherwise, store a GC program and execute it to write directly to the heap bitmap each time an object of that type is allocated. (This is the case that was 7x slower than the other two.) Because the new pointer masks store 1-bit entries instead of 4-bit entries and because using the decoder no longer carries a significant overhead, after this CL (that is, for Go 1.5) there are only two cases: (1) If the type is 128 words or less (no condition about odd or even), store the 1-bit pointer mask directly in the binary and use it to initialize the heap bitmap during malloc. (Implemented in CL 9702.) (2) There is no case 2 anymore. (3) Otherwise, store a GC program and execute it to write directly to the heap bitmap each time an object of that type is allocated. Executing the GC program directly into the heap bitmap (case (3) above) was disabled for the Go 1.5 dev cycle, both to avoid needing to use GC programs for typedmemmove and to avoid updating that code as the heap bitmap format changed. Typedmemmove no longer uses this type information; as of CL 9886 it uses the heap bitmap directly. Now that the heap bitmap format is stable, we reintroduce GC programs and their space savings. Benchmarks for heapBitsSetType, before this CL vs this CL: name old mean new mean delta SetTypePtr 7.59ns × (0.99,1.02) 5.16ns × (1.00,1.00) -32.05% (p=0.000) SetTypePtr8 21.0ns × (0.98,1.05) 21.4ns × (1.00,1.00) ~ (p=0.179) SetTypePtr16 24.1ns × (0.99,1.01) 24.6ns × (1.00,1.00) +2.41% (p=0.001) SetTypePtr32 31.2ns × (0.99,1.01) 32.4ns × (0.99,1.02) +3.72% (p=0.001) SetTypePtr64 45.2ns × (1.00,1.00) 47.2ns × (1.00,1.00) +4.42% (p=0.000) SetTypePtr126 75.8ns × (0.99,1.01) 79.1ns × (1.00,1.00) +4.25% (p=0.000) SetTypePtr128 74.3ns × (0.99,1.01) 77.6ns × (1.00,1.01) +4.55% (p=0.000) SetTypePtrSlice 726ns × (1.00,1.01) 712ns × (1.00,1.00) -1.95% (p=0.001) SetTypeNode1 20.0ns × (0.99,1.01) 20.7ns × (1.00,1.00) +3.71% (p=0.000) SetTypeNode1Slice 112ns × (1.00,1.00) 113ns × (0.99,1.00) ~ (p=0.070) SetTypeNode8 23.9ns × (1.00,1.00) 24.7ns × (1.00,1.01) +3.18% (p=0.000) SetTypeNode8Slice 294ns × (0.99,1.02) 287ns × (0.99,1.01) -2.38% (p=0.015) SetTypeNode64 52.8ns × (0.99,1.03) 51.8ns × (0.99,1.01) ~ (p=0.069) SetTypeNode64Slice 1.13µs × (0.99,1.05) 1.14µs × (0.99,1.00) ~ (p=0.767) SetTypeNode64Dead 36.0ns × (1.00,1.01) 32.5ns × (0.99,1.00) -9.67% (p=0.000) SetTypeNode64DeadSlice 1.43µs × (0.99,1.01) 1.40µs × (1.00,1.00) -2.39% (p=0.001) SetTypeNode124 75.7ns × (1.00,1.01) 79.0ns × (1.00,1.00) +4.44% (p=0.000) SetTypeNode124Slice 1.94µs × (1.00,1.01) 2.04µs × (0.99,1.01) +4.98% (p=0.000) SetTypeNode126 75.4ns × (1.00,1.01) 77.7ns × (0.99,1.01) +3.11% (p=0.000) SetTypeNode126Slice 1.95µs × (0.99,1.01) 2.03µs × (1.00,1.00) +3.74% (p=0.000) SetTypeNode128 85.4ns × (0.99,1.01) 122.0ns × (1.00,1.00) +42.89% (p=0.000) SetTypeNode128Slice 2.20µs × (1.00,1.01) 2.36µs × (0.98,1.02) +7.48% (p=0.001) SetTypeNode130 83.3ns × (1.00,1.00) 123.0ns × (1.00,1.00) +47.61% (p=0.000) SetTypeNode130Slice 2.30µs × (0.99,1.01) 2.40µs × (0.98,1.01) +4.37% (p=0.000) SetTypeNode1024 498ns × (1.00,1.00) 537ns × (1.00,1.00) +7.96% (p=0.000) SetTypeNode1024Slice 15.5µs × (0.99,1.01) 17.8µs × (1.00,1.00) +15.27% (p=0.000) The above compares always using a cached pointer mask (and the corresponding waste of memory) against using the programs directly. Some slowdown is expected, in exchange for having a better general algorithm. The GC programs kick in for SetTypeNode128, SetTypeNode130, SetTypeNode1024, along with the slice variants of those. It is possible that the cutoff of 128 words (bits) should be raised in a followup CL, but even with this low cutoff the GC programs are faster than Go 1.4's "fast path" non-GC program case. Benchmarks for heapBitsSetType, Go 1.4 vs this CL: name old mean new mean delta SetTypePtr 6.89ns × (1.00,1.00) 5.17ns × (1.00,1.00) -25.02% (p=0.000) SetTypePtr8 25.8ns × (0.97,1.05) 21.5ns × (1.00,1.00) -16.70% (p=0.000) SetTypePtr16 39.8ns × (0.97,1.02) 24.7ns × (0.99,1.01) -37.81% (p=0.000) SetTypePtr32 68.8ns × (0.98,1.01) 32.2ns × (1.00,1.01) -53.18% (p=0.000) SetTypePtr64 130ns × (1.00,1.00) 47ns × (1.00,1.00) -63.67% (p=0.000) SetTypePtr126 241ns × (0.99,1.01) 79ns × (1.00,1.01) -67.25% (p=0.000) SetTypePtr128 2.07µs × (1.00,1.00) 0.08µs × (1.00,1.00) -96.27% (p=0.000) SetTypePtrSlice 1.05µs × (0.99,1.01) 0.72µs × (0.99,1.02) -31.70% (p=0.000) SetTypeNode1 16.0ns × (0.99,1.01) 20.8ns × (0.99,1.03) +29.91% (p=0.000) SetTypeNode1Slice 184ns × (0.99,1.01) 112ns × (0.99,1.01) -39.26% (p=0.000) SetTypeNode8 29.5ns × (0.97,1.02) 24.6ns × (1.00,1.00) -16.50% (p=0.000) SetTypeNode8Slice 624ns × (0.98,1.02) 285ns × (1.00,1.00) -54.31% (p=0.000) SetTypeNode64 135ns × (0.96,1.08) 52ns × (0.99,1.02) -61.32% (p=0.000) SetTypeNode64Slice 3.83µs × (1.00,1.00) 1.14µs × (0.99,1.01) -70.16% (p=0.000) SetTypeNode64Dead 134ns × (0.99,1.01) 32ns × (1.00,1.01) -75.74% (p=0.000) SetTypeNode64DeadSlice 3.83µs × (0.99,1.00) 1.40µs × (1.00,1.01) -63.42% (p=0.000) SetTypeNode124 240ns × (0.99,1.01) 79ns × (1.00,1.01) -67.05% (p=0.000) SetTypeNode124Slice 7.27µs × (1.00,1.00) 2.04µs × (1.00,1.00) -71.95% (p=0.000) SetTypeNode126 2.06µs × (0.99,1.01) 0.08µs × (0.99,1.01) -96.23% (p=0.000) SetTypeNode126Slice 64.4µs × (1.00,1.00) 2.0µs × (1.00,1.00) -96.85% (p=0.000) SetTypeNode128 2.09µs × (1.00,1.01) 0.12µs × (1.00,1.00) -94.15% (p=0.000) SetTypeNode128Slice 65.4µs × (1.00,1.00) 2.4µs × (0.99,1.03) -96.39% (p=0.000) SetTypeNode130 2.11µs × (1.00,1.00) 0.12µs × (1.00,1.00) -94.18% (p=0.000) SetTypeNode130Slice 66.3µs × (1.00,1.00) 2.4µs × (0.97,1.08) -96.34% (p=0.000) SetTypeNode1024 16.0µs × (1.00,1.01) 0.5µs × (1.00,1.00) -96.65% (p=0.000) SetTypeNode1024Slice 512µs × (1.00,1.00) 18µs × (0.98,1.04) -96.45% (p=0.000) SetTypeNode124 uses a 124 data + 2 ptr = 126-word allocation. Both Go 1.4 and this CL are using pointer bitmaps for this case, so that's an overall 3x speedup for using pointer bitmaps. SetTypeNode128 uses a 128 data + 2 ptr = 130-word allocation. Both Go 1.4 and this CL are running the GC program for this case, so that's an overall 17x speedup when using GC programs (and I've seen >20x on other systems). Comparing Go 1.4's SetTypeNode124 (pointer bitmap) against this CL's SetTypeNode128 (GC program), the slow path in the code in this CL is 2x faster than the fast path in Go 1.4. The Go 1 benchmarks are basically unaffected compared to just before this CL. Go 1 benchmarks, before this CL vs this CL: name old mean new mean delta BinaryTree17 5.87s × (0.97,1.04) 5.91s × (0.96,1.04) ~ (p=0.306) Fannkuch11 4.38s × (1.00,1.00) 4.37s × (1.00,1.01) -0.22% (p=0.006) FmtFprintfEmpty 90.7ns × (0.97,1.10) 89.3ns × (0.96,1.09) ~ (p=0.280) FmtFprintfString 282ns × (0.98,1.04) 287ns × (0.98,1.07) +1.72% (p=0.039) FmtFprintfInt 269ns × (0.99,1.03) 282ns × (0.97,1.04) +4.87% (p=0.000) FmtFprintfIntInt 478ns × (0.99,1.02) 481ns × (0.99,1.02) +0.61% (p=0.048) FmtFprintfPrefixedInt 399ns × (0.98,1.03) 400ns × (0.98,1.05) ~ (p=0.533) FmtFprintfFloat 563ns × (0.99,1.01) 570ns × (1.00,1.01) +1.37% (p=0.000) FmtManyArgs 1.89µs × (0.99,1.01) 1.92µs × (0.99,1.02) +1.88% (p=0.000) GobDecode 15.2ms × (0.99,1.01) 15.2ms × (0.98,1.05) ~ (p=0.609) GobEncode 11.6ms × (0.98,1.03) 11.9ms × (0.98,1.04) +2.17% (p=0.000) Gzip 648ms × (0.99,1.01) 648ms × (1.00,1.01) ~ (p=0.835) Gunzip 142ms × (1.00,1.00) 143ms × (1.00,1.01) ~ (p=0.169) HTTPClientServer 90.5µs × (0.98,1.03) 91.5µs × (0.98,1.04) +1.04% (p=0.045) JSONEncode 31.5ms × (0.98,1.03) 31.4ms × (0.98,1.03) ~ (p=0.549) JSONDecode 111ms × (0.99,1.01) 107ms × (0.99,1.01) -3.21% (p=0.000) Mandelbrot200 6.01ms × (1.00,1.00) 6.01ms × (1.00,1.00) ~ (p=0.878) GoParse 6.54ms × (0.99,1.02) 6.61ms × (0.99,1.03) +1.08% (p=0.004) RegexpMatchEasy0_32 160ns × (1.00,1.01) 161ns × (1.00,1.00) +0.40% (p=0.000) RegexpMatchEasy0_1K 560ns × (0.99,1.01) 559ns × (0.99,1.01) ~ (p=0.088) RegexpMatchEasy1_32 138ns × (0.99,1.01) 138ns × (1.00,1.00) ~ (p=0.380) RegexpMatchEasy1_1K 877ns × (1.00,1.00) 878ns × (1.00,1.00) ~ (p=0.157) RegexpMatchMedium_32 251ns × (0.99,1.00) 251ns × (1.00,1.01) +0.28% (p=0.021) RegexpMatchMedium_1K 72.6µs × (1.00,1.00) 72.6µs × (1.00,1.00) ~ (p=0.539) RegexpMatchHard_32 3.84µs × (1.00,1.00) 3.84µs × (1.00,1.00) ~ (p=0.378) RegexpMatchHard_1K 117µs × (1.00,1.00) 117µs × (1.00,1.00) ~ (p=0.067) Revcomp 904ms × (0.99,1.02) 904ms × (0.99,1.01) ~ (p=0.943) Template 125ms × (0.99,1.02) 127ms × (0.99,1.01) +1.79% (p=0.000) TimeParse 627ns × (0.99,1.01) 622ns × (0.99,1.01) -0.88% (p=0.000) TimeFormat 655ns × (0.99,1.02) 655ns × (0.99,1.02) ~ (p=0.976) For the record, Go 1 benchmarks, Go 1.4 vs this CL: name old mean new mean delta BinaryTree17 4.61s × (0.97,1.05) 5.91s × (0.98,1.03) +28.35% (p=0.000) Fannkuch11 4.40s × (0.99,1.03) 4.41s × (0.99,1.01) ~ (p=0.212) FmtFprintfEmpty 102ns × (0.99,1.01) 84ns × (0.99,1.02) -18.38% (p=0.000) FmtFprintfString 302ns × (0.98,1.01) 303ns × (0.99,1.02) ~ (p=0.203) FmtFprintfInt 313ns × (0.97,1.05) 270ns × (0.99,1.01) -13.69% (p=0.000) FmtFprintfIntInt 524ns × (0.98,1.02) 477ns × (0.99,1.00) -8.87% (p=0.000) FmtFprintfPrefixedInt 424ns × (0.98,1.02) 386ns × (0.99,1.01) -8.96% (p=0.000) FmtFprintfFloat 652ns × (0.98,1.02) 594ns × (0.97,1.05) -8.97% (p=0.000) FmtManyArgs 2.13µs × (0.99,1.02) 1.94µs × (0.99,1.01) -8.92% (p=0.000) GobDecode 17.1ms × (0.99,1.02) 14.9ms × (0.98,1.03) -13.07% (p=0.000) GobEncode 13.5ms × (0.98,1.03) 11.5ms × (0.98,1.03) -15.25% (p=0.000) Gzip 656ms × (0.99,1.02) 647ms × (0.99,1.01) -1.29% (p=0.000) Gunzip 143ms × (0.99,1.02) 144ms × (0.99,1.01) ~ (p=0.204) HTTPClientServer 88.2µs × (0.98,1.02) 90.8µs × (0.98,1.01) +2.93% (p=0.000) JSONEncode 32.2ms × (0.98,1.02) 30.9ms × (0.97,1.04) -4.06% (p=0.001) JSONDecode 121ms × (0.98,1.02) 110ms × (0.98,1.05) -8.95% (p=0.000) Mandelbrot200 6.06ms × (0.99,1.01) 6.11ms × (0.98,1.04) ~ (p=0.184) GoParse 6.76ms × (0.97,1.04) 6.58ms × (0.98,1.05) -2.63% (p=0.003) RegexpMatchEasy0_32 195ns × (1.00,1.01) 155ns × (0.99,1.01) -20.43% (p=0.000) RegexpMatchEasy0_1K 479ns × (0.98,1.03) 535ns × (0.99,1.02) +11.59% (p=0.000) RegexpMatchEasy1_32 169ns × (0.99,1.02) 131ns × (0.99,1.03) -22.44% (p=0.000) RegexpMatchEasy1_1K 1.53µs × (0.99,1.01) 0.87µs × (0.99,1.02) -43.07% (p=0.000) RegexpMatchMedium_32 334ns × (0.99,1.01) 242ns × (0.99,1.01) -27.53% (p=0.000) RegexpMatchMedium_1K 125µs × (1.00,1.01) 72µs × (0.99,1.03) -42.53% (p=0.000) RegexpMatchHard_32 6.03µs × (0.99,1.01) 3.79µs × (0.99,1.01) -37.12% (p=0.000) RegexpMatchHard_1K 189µs × (0.99,1.02) 115µs × (0.99,1.01) -39.20% (p=0.000) Revcomp 935ms × (0.96,1.03) 926ms × (0.98,1.02) ~ (p=0.083) Template 146ms × (0.97,1.05) 119ms × (0.99,1.01) -18.37% (p=0.000) TimeParse 660ns × (0.99,1.01) 624ns × (0.99,1.02) -5.43% (p=0.000) TimeFormat 670ns × (0.98,1.02) 710ns × (1.00,1.01) +5.97% (p=0.000) This CL is a bit larger than I would like, but the compiler, linker, runtime, and package reflect all need to be in sync about the format of these programs, so there is no easy way to split this into independent changes (at least while keeping the build working at each change). Fixes #9625. Fixes #10524. Change-Id: I9e3e20d6097099d0f8532d1cb5b1af528804989a Reviewed-on: https://go-review.googlesource.com/9888Reviewed-by:
Austin Clements <austin@google.com> Run-TryBot: Russ Cox <rsc@golang.org>
-
- 15 May, 2015 3 commits
-
-
Michael Hudson-Doyle authored
This allows the removal of a fudge in data.go. We have to defer the calls to adddynlib on non-Darwin until after we have decided whether we are externally or internally linking. The Macho/ELF separation could do with some cleaning up, but: code freeze. Fixing this once rather than per-arch is what inspired the previous CLs. Change-Id: I0166f7078a045dc09827745479211247466c0c54 Reviewed-on: https://go-review.googlesource.com/10002 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Michael Hudson-Doyle authored
The only essential difference is elf32 vs elf64, I assume the other differences are bugs in one version or another... Change-Id: Ie6ff33d5574a6592b543df9983eff8fdf88c97a1 Reviewed-on: https://go-review.googlesource.com/10001 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Michael Hudson-Doyle authored
They were all essentially the same. Change-Id: I6e0b548cda6e4bbe2ec3b3025b746d1f6d332d48 Reviewed-on: https://go-review.googlesource.com/10000 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-