- 27 Oct, 2016 5 commits
-
-
Josh Bleecher Snyder authored
With the removal of the old backend, a Label is just a Node. Passes toolstash -cmp. Change-Id: Ia62cb00fbc551efb75a4ed4dc6ed54fca0831dbf Reviewed-on: https://go-review.googlesource.com/32216 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Performance changes are negligible, but that's expected. This is a part of a general effort to eliminate OKEY nodes. Passes toolstash -cmp. Updates #15350 name old alloc/op new alloc/op delta Template 40.6MB ± 0% 40.6MB ± 0% -0.04% (p=0.000 n=9+10) Unicode 33.4MB ± 0% 33.4MB ± 0% ~ (p=0.853 n=10+10) GoTypes 120MB ± 0% 120MB ± 0% -0.03% (p=0.000 n=9+10) Compiler 470MB ± 0% 469MB ± 0% -0.06% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 404k ± 0% 404k ± 0% ~ (p=0.165 n=10+10) Unicode 350k ± 0% 350k ± 0% ~ (p=0.211 n=9+10) GoTypes 1.21M ± 0% 1.21M ± 0% ~ (p=0.315 n=10+10) Compiler 4.35M ± 0% 4.35M ± 0% -0.03% (p=0.001 n=10+10) Change-Id: I17d547bf9568b1ee2514a7ffab930424617f995e Reviewed-on: https://go-review.googlesource.com/32213 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Klaus Post authored
Tests for determinism was not working as intended since io.Copybuffer uses the io.WriterTo if available. This exposed that level 0 (no compression) changed output based on the number of writes and buffers given to the writer. Previously, Write would emit a new raw block (BTYPE=00) for every non-empty call to Write. This CL fixes it such that a raw block is only emitted upon the following conditions: * A full window is obtained (every 65535 bytes) * Flush is called * Close is called Change-Id: I807f866d97e2db7820f11febab30a96266a6cbf1 Reviewed-on: https://go-review.googlesource.com/31174 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
Klaus Post authored
This change makes deflate level 1 (best speed) match across block boundaries. This comes at a small speed penalty, but improves compression on almost all output. Sample numbers on various content types: enwik9: 391052014 -> 382578469 bytes, 77.59 -> 74.28 MB/s adresser.001: 57269799 -> 47756095 bytes, 287.84 -> 357.86 MB/s 10gb: 5233055166 -> 5198328382 bytes, 105.85 -> 96.99 MB/s rawstudio-mint14: 3972329211 -> 3927423364 bytes, 100.07 -> 94.22 MB/s sites: 165556800 -> 163178702 bytes, 72.31 -> 70.15 MB/s objectfiles: 115962472 -> 111649524 bytes, 132.60 -> 128.05 MB/s sharnd.out: 200015283 -> 200015283 bytes, 221.50 -> 218.83 MB/s Change-Id: I62a139e5c06976e803439a4268acede5139b8cfc Reviewed-on: https://go-review.googlesource.com/31640Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Hiroshi Ioka authored
EscScope behaves like EscHeap in current code. There are no need to handle it specially. So remove it and use EscHeap instead. Change-Id: I910106fd147f00e5f4fd52c7dde05128141a5160 Reviewed-on: https://go-review.googlesource.com/32130 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 26 Oct, 2016 35 commits
-
-
Bill O'Farrell authored
The following benchmarks are improved by the amounts shown (Others unaffected beyond the level of noise.) Also adds a test to confirm non-SIMD implementation still correct, even when run on SIMD-capable machine Benchmark old new BenchmarkAddVV/100-18 66148.08 MB/s 117546.19 MB/s 1.8x BenchmarkAddVV/1000-18 70168.27 MB/s 133478.96 MB/s 1.9x BenchmarkAddVV/10000-18 67489.80 MB/s 100010.79 MB/s 1.5x BenchmarkAddVV/100000-18 54329.99 MB/s 69232.45 MB/s 1.3x BenchmarkAddVW/100-18 9929.10 MB/s 14841.31 MB/s 1.5x BenchmarkAddVW/1000-18 10583.31 MB/s 18674.44 MB/s 1.76x BenchmarkAddVW/10000-18 10521.15 MB/s 17484.10 MB/s 1.66x BenchmarkAddVW/100000-18 10616.56 MB/s 18084.27 MB/s 1.7x Change-Id: Ic9234c41a43f6c5e9d0e9377de8b4deeefc428a7 Reviewed-on: https://go-review.googlesource.com/32211Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ben Burkert authored
The CloseWrite method sends a close_notify alert record to the other side of the connection. This record indicates that the sender has finished sending on the connection. Unlike the Close method, the sender may still read from the connection until it recieves a close_notify record (or the underlying connection is closed). This is analogous to a TCP half-close. This is a rework of CL 25159 with fixes for the unstable test. Updates #8579 Change-Id: I47608d2f82a88baff07a90fd64c280ed16a60d5e Reviewed-on: https://go-review.googlesource.com/31318Reviewed-by:
-
Joe Tsai authored
Re-writing the switch statement as a single boolean expression reduces the number of branches that the compiler generates. It is also arguably easier to read as a pair of numeric ranges that valid runes can exist in. No test changes since the existing test does a good job of testing all of the boundaries. This change was to gain back some performance after a correctness fix done in http://golang.org/cl/32123. The correctness fix (CL/32123) slowed down the benchmarks slightly: benchmark old ns/op new ns/op delta BenchmarkIndexRune/10-4 19.3 21.6 +11.92% BenchmarkIndexRune/32-4 33.6 35.2 +4.76% Since the fix relies on utf8.ValidRune, this CL improves benchmarks: benchmark old ns/op new ns/op delta BenchmarkIndexRune/10-4 21.6 20.0 -7.41% BenchmarkIndexRune/32-4 35.2 33.5 -4.83% Change-Id: Ib1ca10a2e29c90e879a8ef9b7221c33e85d015d8 Reviewed-on: https://go-review.googlesource.com/32122 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Fixes #17621. Change-Id: Id3e75c9b7fba2cf8e791c8817f890556ca238e9d Reviewed-on: https://go-review.googlesource.com/32096Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Joe Tsai authored
In all previous versions of Go, the behavior of IndexRune(s, r) where r was utf.RuneError was that it would effectively return the index of any invalid UTF-8 byte sequence (include RuneError). Optimizations made in http://golang.org/cl/28537 and http://golang.org/cl/28546 altered this undocumented behavior such that RuneError would only match on the RuneError rune itself. Although, the new behavior is arguably reasonable, it did break code that depended on the previous behavior. Thus, we add special checks to ensure that we preserve the old behavior. There is a slight performance hit for correctness: benchmark old ns/op new ns/op delta BenchmarkIndexRune/10-4 19.3 21.6 +11.92% BenchmarkIndexRune/32-4 33.6 35.2 +4.76% This only occurs on small strings. The performance hit for larger strings is neglible and not shown. Fixes #17611 Change-Id: I1d863a741213d46c40b2e1724c41245df52502a5 Reviewed-on: https://go-review.googlesource.com/32123 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Adam Langley authored
By using these utility functions, the code can be made a little shorter. Thanks to Omar Shafie for pointing this out in https://golang.org/cl/27393/. Change-Id: I33fd97cf7d60a31d0844ec16c12bba530dcc6f6d Reviewed-on: https://go-review.googlesource.com/32120 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
From lost-in-flight comments on CL 32190. Change-Id: I2029cbac6d24b5944a796b359080011ec3a8da92 Reviewed-on: https://go-review.googlesource.com/32210Reviewed-by:
Caleb Spare <cespare@gmail.com> Reviewed-by:
Martin Möhrmann <martisch@uos.de>
-
Brad Fitzpatrick authored
Fixes #16717 Change-Id: I7b6518609796a537437539c35461a18e9e6f207f Reviewed-on: https://go-review.googlesource.com/32190Reviewed-by:
-
Jaana Burcu Dogan authored
Fixes #17534. Change-Id: I28af74b287a5a09d5f6607a012f3d5d133b04ed2 Reviewed-on: https://go-review.googlesource.com/32017Reviewed-by:
-
Carl Johnson authored
- Removes a subject-verb disagreement. - Documents that PATCH requests also populate PostForm. - Explains that r.PostForm is always set (but blank for GET etc.). Fixes #16609 Change-Id: I6b4693f8eb6db7c66fd9b9cd1df8927f50d46d50 Reviewed-on: https://go-review.googlesource.com/32091Reviewed-by:
-
Joe Tsai authored
Change-Id: I40896fffbffefa359d08abda346933aa996f628d Reviewed-on: https://go-review.googlesource.com/32124Reviewed-by:
-
Than McIntosh authored
Don't include package path when creating LSyms for auto and param variables during Prog generation, and update the DWARF emit routine accordingly (remove the code that chops off package path from names in DWARF var location expressions). Implementation suggested by mdempsky@. The intent of this change is to have saner location expressions in cases where the variable corresponds to a structure field. For example, the SSA compiler's "decompose" phase can take a slice value and break it apart into three scalar variables corresponding to the fields (slice "X" gets split into "X.len", "X.cap", "X.ptr"). In such cases we want the name in the location expression to omit the package path but preserve the original variable name (e.g. "X"). Fixes #16338 Change-Id: Ibc444e7f3454b70fc500a33f0397e669d127daa1 Reviewed-on: https://go-review.googlesource.com/31819 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates #14204 Updates #16450 Updates #16100 Change-Id: Ic283bcec008a8e0bfbcfd8531d30fffe71052531 Reviewed-on: https://go-review.googlesource.com/32024Reviewed-by:
Tom Bergan <tombergan@google.com> Reviewed-by:
-
Brad Fitzpatrick authored
Fixes #14493 Updates #6458 (changes its behavior) Change-Id: I851a8113fd312dae3384e989ec2b70949dc22838 Reviewed-on: https://go-review.googlesource.com/21811 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Quentin Smith <quentin@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I5ad338c90c311bd4cfdcd3d221a1f3e506a97d53 Reviewed-on: https://go-review.googlesource.com/32118 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Chase authored
Sometimes neither the src nor the dst of an escape edge contains the line number appropriate to the edge, so add a field so that can be set correctly. Also updated some of the explanations to be less jargon-y and perhaps more informative, and folded bug example into test. Cleaned up some of the function/method names in esc.go and did a quick sanity check that each "bundling" function was actually called often enough to justify its existence. Fixes #17459. Change-Id: Ieba53ab0a6ba1f7a6c4962bc0b702ede9cc3a3cc Reviewed-on: https://go-review.googlesource.com/31660 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Mikio Hara authored
Change-Id: I6815a8560dd9fe0a0ebd485a0693f7044ba09848 Reviewed-on: https://go-review.googlesource.com/32137Reviewed-by:
-
Austin Clements authored
Currently, markroot delays scanning mark worker stacks until mark termination by putting the mark worker G directly on the rescan list when it encounters one during the mark phase. Without this, since mark workers are non-preemptible, two mark workers that attempt to scan each other's stacks can deadlock. However, this is annoyingly asymmetric and causes some real problems. First, markroot does not own the G at that point, so it's not technically safe to add it to the rescan list. I haven't been able to find a specific problem this could cause, but I suspect it's the root cause of issue #17099. Second, this will interfere with the hybrid barrier, since there is no stack rescanning during mark termination with the hybrid barrier. This commit switches to a different approach. We move the mark worker's call to gcDrain to the system stack and set the mark worker's status to _Gwaiting for the duration of the drain to indicate that it's preemptible. This lets another mark worker scan its G stack while the drain is running on the system stack. We don't return to the G stack until we can switch back to _Grunning, which ensures we don't race with a stack scan. This lets us eliminate the special case for mark worker stack scans and scan them just like any other goroutine. The only subtlety to this approach is that we have to disable stack shrinking for mark workers; they could be referring to captured variables from the G stack, so it's not safe to move their stacks. Updates #17099 and #17503. Change-Id: Ia5213949ec470af63e24dfce01df357c12adbbea Reviewed-on: https://go-review.googlesource.com/31820 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
David du Colombier authored
This issue has been fixed in CL 31271. Fixes #8908. Change-Id: I8015490e2d992e09c664560e42188315e0e0669e Reviewed-on: https://go-review.googlesource.com/32150 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Now that SSA's write barrier pass is generating calls to these, compile doesn't need to look them up. Change-Id: Ib50e5f2c67b247ca280d467c399e23877988bc12 Reviewed-on: https://go-review.googlesource.com/32170 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David du Colombier authored
TestRemoveDevNull was added in CL 31657. However, this test was failing on Plan 9, because /dev/null was considered as a regular file. On Plan 9, there is no special mode to distinguish between device files and regular files. However, files are served by different servers. For example, /dev/null is served by #c (devcons), while /bin/cat is served by #M (devmnt). We chose to consider only the files served by #M as regular files. All files served by different servers will be considered as device files. Fixes #17598. Change-Id: Ibb1c3357d742cf2a7de15fc78c9e436dc31982bb Reviewed-on: https://go-review.googlesource.com/32152Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
This allows callers to invoke f.Usage() themselves and get the default usage handler instead of a panic (from calling a nil function). Fixes #16955. Change-Id: Ie337fd9e1f85daf78c5eae7b5c41d5ad8c1f89bf Reviewed-on: https://go-review.googlesource.com/31576 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
Make the messages grammatically korrect and consistent. Fixes #16844 Change-Id: I7c137b4dc25c0c875ed07b0c64c67ae984c39cbc Reviewed-on: https://go-review.googlesource.com/32112Reviewed-by:
-
Rob Pike authored
For some reason git won't let me write doc/effective_go.html: reword confusing sentence or even doc/effective_go: reword confusing sentence as the subject line for this CL, but that's not important. The actual CL just rewrites one sentence and adds an option to grep in the associated example. Fixes #15875 Change-Id: Iee159ea751caf4b73eacf3dfc86e29032646373f Reviewed-on: https://go-review.googlesource.com/32110Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Currently, if the number of stack barriers for a stack is 0, we'll create a zero-length slice that points just past the end of the stack allocation. This bad pointer causes GC panics. Fix this by creating a nil slice if the stack barrier count is 0. In practice, the only way this can happen is if GODEBUG=gcstackbarrieroff=1 is set because even the minimum size stack reserves space for two stack barriers. Change-Id: I3527c9a504c445b64b81170ee285a28594e7983d Reviewed-on: https://go-review.googlesource.com/31762Reviewed-by:
-
Austin Clements authored
This adds debug code enabled in gccheckmark mode that panics if we attempt to mark an unallocated object. This is a common issue with the hybrid barrier when we're manipulating uninitialized memory that contains stale pointers. This also tends to catch bugs that will lead to "sweep increased allocation count" crashes closer to the source of the bug. Change-Id: I443ead3eac6f316a46f50b106078b524cac317f4 Reviewed-on: https://go-review.googlesource.com/31761Reviewed-by:
-
Austin Clements authored
Currently reflectcall has a subtle dance with write barriers where the assembly code copies the result values from the stack to the in-heap argument frame without write barriers and then calls into the runtime after the fact to invoke the necessary write barriers. For the hybrid barrier (and for ROC), we need to switch to a *pre*-write write barrier, which is very difficult to do with the current setup. We could tie ourselves in knots of subtle reasoning about why it's okay in this particular case to have a post-write write barrier, but this commit instead takes a different approach. Rather than making things more complex, this simplifies reflection calls so that the argument copy is done in Go using normal bulk write barriers. The one difficulty with this approach is that calling into Go requires putting arguments on the stack, but the call* functions "donate" their entire stack frame to the called function. We can get away with this now because the copy avoids using the stack and has copied the results out before we clobber the stack frame to call into the write barrier. The solution in this CL is to call another function, passing arguments in registers instead of on the stack, and let that other function reserve more stack space and setup the arguments for the runtime. This approach seemed to work out the best. I also tried making the call* functions reserve 32 extra bytes of frame for the write barrier arguments and adjust SP up by 32 bytes around the call. However, even with the necessary changes to the assembler to correct the spdelta table, the runtime was still having trouble with the frame layout (and the changes to the assembler caused many other things that do strange things with the SP to fail to assemble). The approach I took doesn't require any funny business with the SP. Updates #17503. Change-Id: Ie2bb0084b24d6cff38b5afb218b9e0534ad2119e Reviewed-on: https://go-review.googlesource.com/31655 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Russ Cox authored
The logic for saving the list of packages was not always preferring to keep error messages around correctly. The missed error led to an internal consistency failure later. Fixes #17119. Change-Id: I9723b5d2518c25e2cac5249e6a7b907be95b521c Reviewed-on: https://go-review.googlesource.com/31812 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Filippo Valsorda authored
Fixes #17430 Change-Id: Ia1c25363d64e3091455ce00644438715aff30a0d Reviewed-on: https://go-review.googlesource.com/31391 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Filippo Valsorda <hi@filippo.io>
-
Russ Cox authored
Fixes #17409. Change-Id: Ib49ff4a467431b5c1e6637e5144979cf0bfba489 Reviewed-on: https://go-review.googlesource.com/31817Reviewed-by:
-
Russ Cox authored
If we leave it for compilation sometimes the error appears first in derived vendor paths, without any indication where they came from. This is better. $ go1.7 build canonical/d cmd/go/testdata/src/canonical/a/a.go:3: non-canonical import path "canonical/a//vendor/c" (should be "canonical/a/vendor/c") cmd/go/testdata/src/canonical/a/a.go:3: can't find import: "canonical/a//vendor/c" $ go build canonical/d package canonical/d imports canonical/b imports canonical/a/: non-canonical import path: "canonical/a/" should be "canonical/a" $ Fixes #16954. Change-Id: I315ccec92a00d98a08c139b3dc4e17dbc640edd0 Reviewed-on: https://go-review.googlesource.com/31668Reviewed-by:
-
Russ Cox authored
This is not strictly illegal but it probably should be (too late) and doesn't mean what it looks like it means: the second key-value pair has the key ",xml". Fixes #14466. Change-Id: I174bccc23fd28affeb87f57f77c6591634ade641 Reviewed-on: https://go-review.googlesource.com/32031 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Munday authored
This CL introduces some minor changes to match rules more closely to the instructions they are targeting. s390x logical operation with immediate instructions typically leave some bits in the target register unchanged. This means for example that an XOR with -1 requires 2 instructions. It is better in cases such as this to create a constant and leave it visible to the compiler so that it can be reused rather than hiding it in the assembler. This CL also tweaks the rules a bit to ensure that constants are folded when possible. Change-Id: I1c6dee31ece00fc3c5fdf6a24f1abbc91dd2db2a Reviewed-on: https://go-review.googlesource.com/31754Reviewed-by:
Keith Randall <khr@golang.org>
-
Alexander Morozov authored
Change-Id: I5c501f598f41241e6d7b21d98a126827a3c3ad9a Reviewed-on: https://go-review.googlesource.com/32018Reviewed-by:
-
Francesc Campoy authored
Currently any warning will make dist fail because the text will be considered as part of the package list. Change-Id: I09a14089cd0448c3779e2f767e9356fe3325d8d9 Reviewed-on: https://go-review.googlesource.com/32111 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Andrew Gerrand <adg@golang.org> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
