- 25 Nov, 2015 7 commits
-
-
Charles Weill authored
Fixes #12963 Change-Id: Icc50dfb6130fe1e189d45f923c2f7408d3cf9401 Reviewed-on: https://go-review.googlesource.com/16047Reviewed-by:
Russ Cox <rsc@golang.org>
-
Aliaksandr Valialkin authored
Benchmark results: benchmark old ns/op new ns/op delta BenchmarkEndToEndPipe-4 7547 7294 -3.35% BenchmarkEndToEndByteBuffer-4 5146 5092 -1.05% BenchmarkEndToEndSliceByteBuffer-4 552779 439768 -20.44% BenchmarkEncodeComplex128Slice-4 266370 266184 -0.07% BenchmarkEncodeFloat64Slice-4 111891 110258 -1.46% BenchmarkEncodeInt32Slice-4 74482 74080 -0.54% BenchmarkEncodeStringSlice-4 84404 84279 -0.15% BenchmarkEncodeInterfaceSlice-4 3942925 3045995 -22.75% BenchmarkDecodeComplex128Slice-4 451837 415282 -8.09% BenchmarkDecodeFloat64Slice-4 283584 262558 -7.41% BenchmarkDecodeInt32Slice-4 246571 237383 -3.73% BenchmarkDecodeStringSlice-4 734210 479625 -34.67% BenchmarkDecodeInterfaceSlice-4 4778225 4160935 -12.92% benchmark old allocs new allocs delta BenchmarkEndToEndPipe-4 3 2 -33.33% BenchmarkEndToEndByteBuffer-4 3 2 -33.33% BenchmarkEndToEndSliceByteBuffer-4 1002 402 -59.88% BenchmarkEncodeComplex128Slice-4 1 1 +0.00% BenchmarkEncodeFloat64Slice-4 1 1 +0.00% BenchmarkEncodeInt32Slice-4 1 1 +0.00% BenchmarkEncodeStringSlice-4 1 1 +0.00% BenchmarkEncodeInterfaceSlice-4 3001 1 -99.97% BenchmarkDecodeComplex128Slice-4 188 185 -1.60% BenchmarkDecodeFloat64Slice-4 188 185 -1.60% BenchmarkDecodeInt32Slice-4 188 185 -1.60% BenchmarkDecodeStringSlice-4 2188 1185 -45.84% BenchmarkDecodeInterfaceSlice-4 6197 4194 -32.32% benchmark old bytes new bytes delta BenchmarkEndToEndPipe-4 64 48 -25.00% BenchmarkEndToEndByteBuffer-4 64 48 -25.00% BenchmarkEndToEndSliceByteBuffer-4 34551 10554 -69.45% BenchmarkEncodeComplex128Slice-4 55 55 +0.00% BenchmarkEncodeFloat64Slice-4 33 33 +0.00% BenchmarkEncodeInt32Slice-4 32 32 +0.00% BenchmarkEncodeStringSlice-4 36 36 +0.00% BenchmarkEncodeInterfaceSlice-4 144555 347 -99.76% BenchmarkDecodeComplex128Slice-4 28240 28097 -0.51% BenchmarkDecodeFloat64Slice-4 11840 11697 -1.21% BenchmarkDecodeInt32Slice-4 10817 10673 -1.33% BenchmarkDecodeStringSlice-4 56128 39985 -28.76% BenchmarkDecodeInterfaceSlice-4 132565 100421 -24.25% Change-Id: Ief7c7706b1f2916486ab7190b81aafbb16b70f1e Reviewed-on: https://go-review.googlesource.com/13660Reviewed-by:
-
Erik Dubbelboer authored
json.Number is a special case which didn't have any checks and could result in invalid JSON. Fixes #10281 Change-Id: Ie3e726e4d6bf6a6aba535d36f6107013ceac913a Reviewed-on: https://go-review.googlesource.com/12250Reviewed-by:
-
Joe Tsai authored
CRC-32 computation is stateless and the p slice does not get stored anywhere. Thus, we mark the assembly functions as noescape so that it doesn't believe that p leaks in: func Update(crc uint32, tab *Table, p []byte) uint32 Before: ./crc32.go:153: leaking param: p After: ./crc32.go:153: Update p does not escape Change-Id: I52ba35b6cc544fff724327140e0c27898431d1dc Reviewed-on: https://go-review.googlesource.com/17069Reviewed-by:
-
Brad Fitzpatrick authored
This compares the behavior of server handlers and the net/http Transport in both HTTP/1 and HTTP/2 mode and verifies they're the same. This also moves some client<->server tests into clientserver_test.go. Many of them were in serve_test.go or transport_test.go but were basically testing both. h2_bundle.go is an update of the golang.org/x/net/http2 code from https://golang.org/cl/17204 (x/net git rev c745c36eab10) Fixes #13315 Fixes #13316 Fixes #13317 Fixes other stuff found in the process too Updates #6891 (http2 support in general) Change-Id: Id9c45fad44cdf70ac95d2b89e578d66e882d3cc2 Reviewed-on: https://go-review.googlesource.com/17205Reviewed-by:
Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Hudson-Doyle authored
Fixes testshared on arm64 and ppc64le. Change-Id: Ie94bc0c85c7666fbb5ab6fc6d3dbb180407a9955 Reviewed-on: https://go-review.googlesource.com/17212Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Shenghou Ma authored
We need a runtime check because the original issue is encountered when running cross compiled windows program from linux. It's better to give a meaningful crash message earlier than to segfault later. The added test should not impose any measurable overhead to Go programs. For #12415. Change-Id: Ib4a24ef560c09c0585b351d62eefd157b6b7f04c Reviewed-on: https://go-review.googlesource.com/14207Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 24 Nov, 2015 25 commits
-
-
Robert Griesemer authored
This is a comment/documentation change only but for a minor code change in the file and package_ methods (move recognition of semi to match grammar better). Per request from r. Change-Id: I81ec985cc5831074d9eb5e8ffbf7e59466284819 Reviewed-on: https://go-review.googlesource.com/17202Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
The prefix includes a semicolon. Change-Id: I4bdb79aa9931e835e297f3ea2c46a001cd123d56 Reviewed-on: https://go-review.googlesource.com/17200Reviewed-by:
-
Jakub Čajka authored
This change strips non-free license from Mark.Twain-Tom.Sawyer.txt along with all reference to Project Gutenberg in the file and the whole source tree. Making the file public domain again. Fixes #13216 Change-Id: I2f41b0de225f627dde152efe93c006a4c24be668 Reviewed-on: https://go-review.googlesource.com/17196Reviewed-by:
-
Austin Clements authored
Write barriers in gcFlushBgCredit lead to very subtle bugs because it executes after the getfull barrier. I tracked some bugs of this form down before go:nowritebarrierrec was implemented. Ensure that they don't reappear by making gcFlushBgCredit go:nowritebarrierrec. Change-Id: Ia5ca2dc59e6268bce8d8b4c87055bd0f6e19bed2 Reviewed-on: https://go-review.googlesource.com/17052Reviewed-by:
-
Austin Clements authored
sighandler may run during STW, so write barriers are not allowed. Change-Id: Icdf46be10ea296fd87e73ab56ebb718c5d3c97ac Reviewed-on: https://go-review.googlesource.com/17007Reviewed-by:
-
Rob Pike authored
Fixes #13378 Change-Id: Ia78624ca1aa36ee906cef15416ea5554fa8229f2 Reviewed-on: https://go-review.googlesource.com/17201Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
David du Colombier authored
On multiprocessor machines, a file descriptor could be closed twice in forkAndExecInChild. Consequently, the close syscall returns the "fd out of range or not open" error and forkAndExecInChild fails. This changes forkAndExecInChild to ignore the error returned by close(fd), as on other operating systems. Fixes #12851. Change-Id: I96a8463ce6599bfd1362353283e0329a00f738da Reviewed-on: https://go-review.googlesource.com/17188Reviewed-by:
-
Elias Naur authored
Replace the cross platform but unsafe [4]uintptr type with a OS specific type, sigset. Most OSes already define sigset, and this change defines a suitable sigset for the OSes that don't (darwin, openbsd). The OSes that don't use m.sigmask (windows, plan9, nacl) now defines sigset as the empty type, struct{}. The gain is strongly typed access to m.sigmask, saving a dynamic size sanity check and unsafe.Pointer casting. Also, some storage is saved for each M, since [4]uinptr was conservative for most OSes. The cost is that OSes that don't need m.sigmask has to define sigset. completes ./all.bash with GOOS linux, on amd64 completes ./make.bash with GOOSes openbsd, android, plan9, windows, darwin, solaris, netbsd, freebsd, dragonfly, all amd64. With GOOS=nacl ./make.bash failed with a seemingly unrelated error. [Replay of CL 16942 by Elias Naur.] Change-Id: I98f144d626033ae5318576115ed635415ac71b2c Reviewed-on: https://go-review.googlesource.com/17033Reviewed-by: -
Michael Hudson-Doyle authored
This is a bit ugly but it's a useful test. Run go install -buildmode=shared std and then go run run.go -linkshared (it passes on linux/amd64). Change-Id: I5684c79cd03817fa1fc399788b7320f8535c08da Reviewed-on: https://go-review.googlesource.com/16343Reviewed-by:
-
Carlos Cirello authored
Change-Id: I9e968c03c6615a539b18701c84f830898242441d Reviewed-on: https://go-review.googlesource.com/13926Reviewed-by:
-
Aaron Jacobs authored
Change-Id: Idd9523949ee4f2f304b12be39f8940ba34a420be Reviewed-on: https://go-review.googlesource.com/16361Reviewed-by:
-
Caleb Spare authored
Before, we reset the timer at the end of T.Parallel, which is okay assuming that T.Parallel is the first thing in the test. Snapshot the elapsed time at the beginning of Parallel and include it in the total duration so that any time spent in the test before calling Parallel is reported in the test duration as well. Updates #12243. Change-Id: Ieca553e1f801e16b9b6416463fa8f7fa65425185 Reviewed-on: https://go-review.googlesource.com/16989Reviewed-by:
-
dvyukov authored
These tests were failing on one of the versions of cl/9345 ("runtime: simplify buffered channels"). Change-Id: I920ffcd28de428bcb7c2d5a300068644260e1017 Reviewed-on: https://go-review.googlesource.com/16416Reviewed-by: -
Ilya Tocar authored
Results are a bit noisy, but show good improvement (haswell) name old time/op new time/op delta Memclr5-48 6.06ns ± 8% 5.65ns ± 8% -6.81% (p=0.000 n=20+20) Memclr16-48 5.75ns ± 6% 5.71ns ± 6% ~ (p=0.545 n=20+19) Memclr64-48 6.54ns ± 5% 6.14ns ± 9% -6.12% (p=0.000 n=18+20) Memclr256-48 10.1ns ±12% 9.9ns ±14% ~ (p=0.285 n=20+19) Memclr4096-48 104ns ± 8% 57ns ±15% -44.98% (p=0.000 n=20+20) Memclr65536-48 2.45µs ± 5% 2.43µs ± 8% ~ (p=0.665 n=16+20) Memclr1M-48 58.7µs ±13% 56.4µs ±11% -3.92% (p=0.033 n=20+19) Memclr4M-48 233µs ± 9% 234µs ± 9% ~ (p=0.728 n=20+19) Memclr8M-48 469µs ±11% 472µs ±16% ~ (p=0.947 n=20+20) Memclr16M-48 947µs ±10% 916µs ±10% ~ (p=0.050 n=20+19) Memclr64M-48 10.9ms ±10% 4.5ms ± 9% -58.43% (p=0.000 n=20+20) GoMemclr5-48 3.80ns ±13% 3.38ns ± 6% -11.02% (p=0.000 n=20+20) GoMemclr16-48 3.34ns ±15% 3.40ns ± 9% ~ (p=0.351 n=20+20) GoMemclr64-48 4.10ns ±15% 4.04ns ±10% ~ (p=1.000 n=20+19) GoMemclr256-48 7.75ns ±20% 7.88ns ± 9% ~ (p=0.227 n=20+19) name old speed new speed delta Memclr5-48 826MB/s ± 7% 886MB/s ± 8% +7.32% (p=0.000 n=20+20) Memclr16-48 2.78GB/s ± 5% 2.81GB/s ± 6% ~ (p=0.550 n=20+19) Memclr64-48 9.79GB/s ± 5% 10.44GB/s ±10% +6.64% (p=0.000 n=18+20) Memclr256-48 25.4GB/s ±14% 25.6GB/s ±12% ~ (p=0.647 n=20+19) Memclr4096-48 39.4GB/s ± 8% 72.0GB/s ±13% +82.81% (p=0.000 n=20+20) Memclr65536-48 26.6GB/s ± 6% 27.0GB/s ± 9% ~ (p=0.517 n=17+20) Memclr1M-48 17.9GB/s ±12% 18.5GB/s ±11% ~ (p=0.068 n=20+20) Memclr4M-48 18.0GB/s ± 9% 17.8GB/s ±14% ~ (p=0.547 n=20+20) Memclr8M-48 17.9GB/s ±10% 17.8GB/s ±14% ~ (p=0.947 n=20+20) Memclr16M-48 17.8GB/s ± 9% 18.4GB/s ± 9% ~ (p=0.050 n=20+19) Memclr64M-48 6.19GB/s ±10% 14.87GB/s ± 9% +140.11% (p=0.000 n=20+20) GoMemclr5-48 1.31GB/s ±10% 1.48GB/s ± 6% +13.06% (p=0.000 n=19+20) GoMemclr16-48 4.81GB/s ±14% 4.71GB/s ± 8% ~ (p=0.341 n=20+20) GoMemclr64-48 15.7GB/s ±13% 15.8GB/s ±11% ~ (p=0.967 n=20+19) Change-Id: I393f3f20e2f31538d1b1dd70d6e5c201c106a095 Reviewed-on: https://go-review.googlesource.com/16773 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Klaus Post <klauspost@gmail.com> Reviewed-by:
-
Dave Cheney authored
Fixes #11959 Fixes #12035 Skip the CallbackGC test on linux/arm. This test takes between 30 and 60 seconds to run by itself, and is run 4 times over the course of ./run.bash (once during the runtime test, three times more later in the build). Change-Id: I4e7d3046031cd8c08f39634bdd91da6e00054caf Reviewed-on: https://go-review.googlesource.com/14485Reviewed-by:
-
Alex Brainman authored
Original code is mistakenly panics on VirtualAlloc failure - we want it to go looking for smaller memory region that VirtualAlloc will succeed to allocate. Also return immediately if VirtualAlloc succeeds. See rsc comment on issue #12587 for details. I still don't have a test for this. So I can only hope that this Fixes #12587 Change-Id: I052068ec627fdcb466c94ae997ad112016f734b7 Reviewed-on: https://go-review.googlesource.com/17169Reviewed-by:
-
Robert Griesemer authored
See https://go-review.googlesource.com/#/c/17047/ for the bug fix. Change-Id: Id5b0a37439d0f8f1e668f7c2ac84335b37f3a300 Reviewed-on: https://go-review.googlesource.com/17177Reviewed-by:
-
Andrew Gerrand authored
Fixes #13073 Change-Id: I4fd9c6c61f1b9d49f66816839ca35209b4147ae3 Reviewed-on: https://go-review.googlesource.com/17167Reviewed-by:
-
Robert Griesemer authored
Get rid of residue after removing old parser. Change-Id: I0dace1037d50959071a082c276f9f374eef6edb2 Reviewed-on: https://go-review.googlesource.com/17179 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
-
Caleb Spare authored
It relates to an obsolete notion of 'skipped-but-okay' tests. Fixes #12394 Change-Id: Ib7e6444dc8565e1390bd42d65d30fac136593f78 Reviewed-on: https://go-review.googlesource.com/17000 Run-TryBot: Caleb Spare <cespare@gmail.com> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitri Shuralyov <shurcool@gmail.com>
-
Michael Hudson-Doyle authored
These are methods that are "obviously" going to get inlined -- until you build with -l, when they can trigger a stack split at a bad time. Fixes #11482 Change-Id: Ia065c385978a2e7fe9f587811991d088c4d68325 Reviewed-on: https://go-review.googlesource.com/17165 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Commit bbd1a1c7 prevented SIGPROF from scanning stacks that were being copied, but it didn't prevent a stack copy (specifically a stack shrink) from happening while SIGPROF is scanning the stack. As a result, a stack copy may adjust stack barriers while SIGPROF is in the middle of scanning a stack, causing SIGPROF to panic when it detects an inconsistent stack barrier. Fix this by taking the stack barrier lock while adjusting the stack. In addition to preventing SIGPROF from scanning this stack, this will block until any in-progress SIGPROF is done scanning the stack. For 1.5.2. Fixes #13362. Updates #12932. Change-Id: I422219c363054410dfa56381f7b917e04690e5dd Reviewed-on: https://go-review.googlesource.com/17191 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Alex Brainman authored
Calling timeBeginPeriod changes Windows global timer resolution from 15ms to 1ms. This used to improve Go runtime scheduler performance, but not anymore. Thanks to @aclements, scheduler now behaves the same way if we call timeBeginPeriod or not. Remove call to timeBeginPeriod, since it is machine global resource, and there are downsides of using low timer resolution. See issue #8687 for details. Fixes #8687 Change-Id: Ib7e41aa4a81861b62a900e0e62776c9ef19bfb73 Reviewed-on: https://go-review.googlesource.com/17164Reviewed-by:
Austin Clements <austin@google.com> Reviewed-by:
Yasuhiro MATSUMOTO <mattn.jp@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
-
Robert Griesemer authored
- moved yySymType and token constants (L...) to lex.go - removed oldparser flag and related code - removed go generate that generated y.go Fixes #13240. Change-Id: I2576ec61ee1efe482f2a5132175725c9c02ef977 Reviewed-on: https://go-review.googlesource.com/17176Reviewed-by:
-
Ian Lance Taylor authored
This relocation is found in libgcc.a in the .eh_frame, and therefore needs to be handled when doing an internal link. Fixes #13375. Change-Id: Idd9e8178e08851a101b43261a30939bcfaf394f9 Reviewed-on: https://go-review.googlesource.com/17173 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
- 23 Nov, 2015 8 commits
-
-
Rob Pike authored
It is not important to add, since it's only used for creating an error message, but for consistency in the API between text/template and html/template it should be provided here. The implementation just calls the one in text/template. Fixes #13349. Change-Id: I0882849e06a58f1e38b00eb89d79ac39777309b2 Reviewed-on: https://go-review.googlesource.com/17172Reviewed-by:
-
Robert Griesemer authored
Introduce a try_ntype function which doesn't return an error upon not finding a type. Use it instead of having separate repeated token checks. Simpler, less code, and more efficient. Change-Id: I81e482158b71901eb179470269349688636aa0ba Reviewed-on: https://go-review.googlesource.com/17157Reviewed-by:
Chris Manghane <cmang@golang.org>
-
Rob Pike authored
Change-Id: Icdce5cdb8676c3bcb73bd943b406000252509521 Reviewed-on: https://go-review.googlesource.com/17174Reviewed-by:
-
Nodir Turakulov authored
Sscanf doc says: Newlines in the input must match newlines in the format. However Sscanf didn't check newline in the end of input (EOF). A test for the case is broken. * check newline in EOF * fix the test * slightly simplify ss.doScanf Fixes #12788 Change-Id: Iaf6b7d81324a72e557543ac22ecea5cecb72e0d6 Reviewed-on: https://go-review.googlesource.com/16165 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
This improves the documentation comment on gcMarkDone, replaces a recursive call with a simple goto, and disables preemption before stopping the world in accordance with the documentation comment on stopTheWorldWithSema. Updates #13363, but, sadly, doesn't fix it. Change-Id: I6cb2a5836b35685bf82f7b1ce7e48a7625906656 Reviewed-on: https://go-review.googlesource.com/17149Reviewed-by:
Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
This improves stack barrier debugging messages in various ways: 1) Rather than printing only the remaining stack barriers (of which there may be none, which isn't very useful), print all of the G's stack barriers with a marker at the position the stack itself has unwound to and a marker at the problematic stack barrier (where applicable). 2) Rather than crashing if we encounter a stack barrier when there are no more stkbar entries, print the same debug message we would if we had encountered a stack barrier at an unexpected location. Hopefully this will help with debugging #12528. Change-Id: I2e6fe6a778e0d36dd8ef30afd4c33d5d94731262 Reviewed-on: https://go-review.googlesource.com/17147Reviewed-by:
-
Austin Clements authored
The stack barrier locking functions use a simple cas lock because they need to support trylock, but currently don't increment g.m.locks. This is okay right now because they always run on the system stack or the signal stack and are hence non-preemtible, but this could lead to difficult-to-reproduce deadlocks if these conditions change in the future. Make these functions more robust by incrementing g.m.locks and making them nosplit to enforce non-preemtibility. Change-Id: I73d60a35bd2ad2d81c73aeb20dbd37665730eb1b Reviewed-on: https://go-review.googlesource.com/17058 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ingo Oeser <nightlyone@googlemail.com> Reviewed-by:
-
Ian Lance Taylor authored
Fixes #13344. Change-Id: I33c6721fd33d144c85c87840ddf27ce15aa72328 Reviewed-on: https://go-review.googlesource.com/17151 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Minux Ma <minux@golang.org>
-
