- 22 Nov, 2016 19 commits
-
-
Brad Fitzpatrick authored
TBR=See https://golang.org/cl/33244 and review there. Updates #17929 Change-Id: I7cb0b666469dba35426d1f0ae1b185e0bdfeac05 Reviewed-on: https://go-review.googlesource.com/33474Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
This changes makes the output of `go env` the same as on other operating systems. Fixes #18013. Change-Id: I3079e14dcf7b30c75ec3fde6c78cb95721111320 Reviewed-on: https://go-review.googlesource.com/33396Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
Applies the fix from CL 32920 to the new test TestSampledHeapAllocProfile introduced in CL 33422. The test should be skipped rather than fail if there is only one executable region of memory. Updates #17852. Change-Id: Id8c47b1f17ead14f02a58a024c9a04ebb8ec0429 Reviewed-on: https://go-review.googlesource.com/33453 Run-TryBot: Michael Munday <munday@ca.ibm.com> Reviewed-by:
-
Russ Cox authored
The expected default behavior (no explicit GOTRACEBACK setting) is for the stack trace to start in user code, eliding unnecessary runtime frames that led up to the actual trace printing code. The idea was that the first line number printed was the one that crashed. For #5832 we added code to show 'panic' frames so that if code panics and then starts running defers and then we trace from there, the panic frame can help explain why the code seems to have made a call not present in the code. But that's only needed for panics between two different call frames, not the panic at the very top of the stack trace. Fix the fix to again elide the runtime code at the very top of the stack trace. Simple panic: package main func main() { var x []int println(x[1]) } Before this CL: panic: runtime error: index out of range goroutine 1 [running]: panic(0x1056980, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:531 +0x1cf main.main() /tmp/x.go:5 +0x5 After this CL: panic: runtime error: index out of range goroutine 1 [running]: main.main() /tmp/x.go:5 +0x5 Panic inside defer triggered by panic: package main func main() { var x []int defer func() { println(x[1]) }() println(x[2]) } Before this CL: panic: runtime error: index out of range panic: runtime error: index out of range goroutine 1 [running]: panic(0x1056aa0, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:531 +0x1cf main.main.func1(0x0, 0x0, 0x0) /tmp/y.go:6 +0x62 panic(0x1056aa0, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:489 +0x2cf main.main() /tmp/y.go:8 +0x59 The middle panic is important: it explains why main.main ended up calling main.main.func1 on a line that looks like a call to println. The top panic is noise. After this CL: panic: runtime error: index out of range panic: runtime error: index out of range goroutine 1 [running]: main.main.func1(0x0, 0x0, 0x0) /tmp/y.go:6 +0x62 panic(0x1056ac0, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:489 +0x2cf main.main() /tmp/y.go:8 +0x59 Fixes #17901. Change-Id: Id6d7c76373f7a658a537a39ca32b7dc23e1e76aa Reviewed-on: https://go-review.googlesource.com/33165 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Brad Fitzpatrick authored
TBR=See https://golang.org/cl/33244 and review there. Updates #17929 Change-Id: I37b49318a9203b16c0c788926039288b99a36ce5 Reviewed-on: https://go-review.googlesource.com/33450Reviewed-by:
-
Michael Matloob authored
When debug is 0, emit the compressed proto format. The debug>0 format stays the same. Updates #16093 Change-Id: I45aa1874a22d34cf44dd4aa78bbff9302381cb34 Reviewed-on: https://go-review.googlesource.com/33422 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates #17929 Change-Id: Ibc711d39d9ff83458d213778117493796b678aa7 Reviewed-on: https://go-review.googlesource.com/33437Reviewed-by:
-
Brad Fitzpatrick authored
Updates #17929 Change-Id: Ie90736cfce3fc5f23cbe0a0f1971476705aac5f9 Reviewed-on: https://go-review.googlesource.com/33436Reviewed-by:
-
Brad Fitzpatrick authored
Day 0 is as invalid as day 32. Fixes #17874 Change-Id: I52109d12bafd6d957d00c44d540cb88389fff0a7 Reviewed-on: https://go-review.googlesource.com/33429 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
When I added t.Parallel to some tests earlier, I overlooked some using the global "Get" func, which uses DefaultTransport. The DefaultTransport can have its CloseIdleConnections called by other parallel tests. Use a private Transport instead. Fixes #18006 Change-Id: Ia4faca5bac235cfa95dcf2703c25f3627112a5e9 Reviewed-on: https://go-review.googlesource.com/33432 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
When we raise a signal that was delivered to C code, it's possible that the kernel will not deliver it immediately. This is especially possible on Darwin where we use send the signal to the entire process rather than just the current thread. Sleep for a millisecond after sending the signal to give it a chance to be delivered before we restore the Go signal handler. In most real cases the program is going to crash at this point, so sleeping is kind of irrelevant anyhow. Fixes #14809. Change-Id: Ib2c0d2c4e240977fb4535dc1dd2bdc50d430eb85 Reviewed-on: https://go-review.googlesource.com/33300 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
When CC is set in the environment, the mkEnv function sets its version of CC to the first word $CC and sets GOGCCFLAGS to the remainder. That worked since Go 1 but was broken accidentally by https://golang.org/cl/6409, which changed the code such that `go env` calls mkEnv twice. The second call to mkEnv would clobber GOGCCFLAGS based on the value of CC set by the first call. Go back to the old handling by only calling mkEnv once. Fixes #15457. Change-Id: I000a1ebcc48684667e48f2b9b24605867b9e06cd Reviewed-on: https://go-review.googlesource.com/33293Reviewed-by:
-
David Crawshaw authored
Introduce R_WEAKADDROFF, a "weak" variation of the R_ADDROFF relocation that will only reference the type described if it is in some other way reachable. Use this for the ptrToThis field in reflect type information where it is safe to do so (that is, types that don't need to be included for interface satisfaction, and types that won't cause the compiler to recursively generate an endless series of ptr-to-ptr-to-ptr-to... types). Also fix a small bug in reflect, where StructOf was not clearing the ptrToThis field of new types. Fixes #17931 Change-Id: I4d3b53cb9c916c97b3b16e367794eee142247281 Reviewed-on: https://go-review.googlesource.com/33427 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
See issues for details. We can expand this test during the Go 1.9 cycle. Updates #18008 Change-Id: I78b6b7e8dede414769be97898e29f969bc2a9651 Reviewed-on: https://go-review.googlesource.com/33430Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Russ Cox authored
After x.ProbablyPrime(n) passes the n Miller-Rabin rounds, add a Baillie-PSW test before declaring x probably prime. Although the provable error bounds are unchanged, the empirical error bounds drop dramatically: there are no known inputs for which Baillie-PSW gives the wrong answer. For example, before this CL, big.NewInt(443*1327).ProbablyPrime(1) == true. Now it is (correctly) false. The new Baillie-PSW test is two pieces: an added Miller-Rabin round with base 2, and a so-called extra strong Lucas test. (See the references listed in prime.go for more details.) The Lucas test takes about 3.5x as long as the Miller-Rabin round, which is close to theoretical expectations. name time/op ProbablyPrime/Lucas 2.91ms ± 2% ProbablyPrime/MillerRabinBase2 850µs ± 1% ProbablyPrime/n=0 3.75ms ± 3% The speed of prime testing for a prime input does get slower: name old time/op new time/op delta ProbablyPrime/n=1 849µs ± 1% 4521µs ± 1% +432.31% (p=0.000 n=10+9) ProbablyPrime/n=5 4.31ms ± 3% 7.87ms ± 1% +82.70% (p=0.000 n=10+10) ProbablyPrime/n=10 8.52ms ± 3% 12.28ms ± 1% +44.11% (p=0.000 n=10+10) ProbablyPrime/n=20 16.9ms ± 2% 21.4ms ± 2% +26.35% (p=0.000 n=9+10) However, because the Baillie-PSW test is only added when the old ProbablyPrime(n) would return true, testing composites runs at the same speed as before, except in the case where the result would have been incorrect and is now correct. In particular, the most important use of this code is for generating random primes in crypto/rand. That use spends essentially all its time testing composites, so it is not slowed down by the new Baillie-PSW check: name old time/op new time/op delta Prime 104ms ±22% 111ms ±16% ~ (p=0.165 n=10+10) Thanks to Serhat Şevki Dinçer for CL 20170, which this CL builds on. Fixes #13229. Change-Id: Id26dde9b012c7637c85f2e96355d029b6382812a Reviewed-on: https://go-review.googlesource.com/30770 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Cherry Zhang authored
This check was originally implemented by Vladimir in https://go-review.googlesource.com/c/31489/1/src/runtime/internal/atomic/atomic_mipsx.go#30 but removed due to my comment (Sorry!). This CL adds it back. Fixes #17786. Change-Id: I7ff4c2539fc9e2afd8199964b587a8ccf093b896 Reviewed-on: https://go-review.googlesource.com/33431 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:
-
Brad Fitzpatrick authored
Updates #17937 Change-Id: Ic822da1786a983b3b7bca21b68c3d5fc4bdfaee2 Reviewed-on: https://go-review.googlesource.com/33428 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
In Plan 9's shell, GOBIN= \ foo bar is the same as GOBIN=foo bar Write what was meant, which is GOBIN=() \ foo bar Fixes #17737. Change-Id: Ie5a1b51a7cec950b5e78bbbe99cbc3cfe102f980 Reviewed-on: https://go-review.googlesource.com/33144 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Quentin Smith <quentin@golang.org> Reviewed-by:
David du Colombier <0intro@gmail.com>
-
Russ Cox authored
Fixes #17743. Change-Id: Ib5afb6248bb060f2ad8dd3d5f78e95271af62a57 Reviewed-on: https://go-review.googlesource.com/33135 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Caleb Spare <cespare@gmail.com>
-
- 21 Nov, 2016 8 commits
-
-
Brad Fitzpatrick authored
Change-Id: If754de6c44cf0ec4192101432e4065cc7a28e862 Reviewed-on: https://go-review.googlesource.com/33425Reviewed-by:
-
Brad Fitzpatrick authored
Updates #18008 Change-Id: I8fde0d71d15b416db4d262f6db8ef32a209a192f Reviewed-on: https://go-review.googlesource.com/33426Reviewed-by:
-
Ian Lance Taylor authored
The gccgo compiler does not have the standard packages available, so it can not check for violations of internal references. Also, the gccgo compiler can not read runtime/internal/sys/zversion.go; in fact, the file does not even exist for gccgo. Change-Id: Ibadf16b371621ad1b87b6e858c5eb233913e179d Reviewed-on: https://go-review.googlesource.com/33295 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
We recently added these large zip64 tests. They're slow-ish already, but fast enough in non-race mode with t.Parallel. But in race mode, the concurrency makes them much slower than the normal non-race-to-race multiplier. They're taking so long now that it's causing test failures when it sometimes is over the test timeout threshold. Change-Id: I02f4ceaa9d6cab826708eb3860f47a57b05bdfee Reviewed-on: https://go-review.googlesource.com/33423 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Should fix flakes like: https://build.golang.org/log/c8da331317064227f38d5ef57ed7dba563ba1b38 --- FAIL: TestClientTimeout_h1 (0.35s) client_test.go:1263: timeout after 200ms waiting for timeout of 100ms FAIL Change-Id: I0a4dba607524e8d7a00f498e27d9598acde5d222 Reviewed-on: https://go-review.googlesource.com/33420 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Cherry Zhang authored
Updates #17786. Will fix mips(32) when the port is fully landed. Change-Id: I00d4ff666ec14a38cadbcd52569b347bb5bc8b75 Reviewed-on: https://go-review.googlesource.com/33236 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:
-
Cherry Zhang authored
Make atomic access on 32-bit architectures happy. Updates #17786. Change-Id: I42de63ff1381af42124dc51befc887160f71797d Reviewed-on: https://go-review.googlesource.com/33235 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:
Austin Clements <austin@google.com>
-
Michael Matloob authored
count profiles with debug=1 retain their previous format. Also add a test check for the proto profiles since all runtime/pprof tests only look at the debug=1 profiles. Change-Id: Ibe805585b597e5d3570807115940a1dc4535c03f Reviewed-on: https://go-review.googlesource.com/33148 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by:
-
- 20 Nov, 2016 2 commits
-
-
Austin Clements authored
If the scheduler has no user work and there's no GC work visible, it puts the P to sleep (or blocks on the network). However, if we later enqueue more GC work, there's currently nothing that specifically wakes up the scheduler to let it start an idle GC worker. As a result, we can underutilize the CPU during GC if Ps have been put to sleep. Fix this by making GC wake idle Ps when work buffers are put on the full list. We already have a hook to do this, since we use this to preempt a random P if we need more dedicated workers. We expand this hook to instead wake an idle P if there is one. The logic we use for this is identical to the logic used to wake an idle P when we ready a goroutine. To make this really sound, we also fix the scheduler to re-check the idle GC worker condition after releasing its P. This closes a race where 1) the scheduler checks for idle work and finds none, 2) new work is enqueued but there are no idle Ps so none are woken, and 3) the scheduler releases its P. There is one subtlety here. Currently we call enlistWorker directly from putfull, but the gcWork is in an inconsistent state in the places that call putfull. This isn't a problem right now because nothing that enlistWorker does touches the gcWork, but with the added call to wakep, it's possible to get a recursive call into the gcWork (specifically, while write barriers are disallowed, this can do an allocation, which can dispose a gcWork, which can put a workbuf). To handle this, we lift the enlistWorker calls up a layer and delay them until the gcWork is in a consistent state. Fixes #14179. Change-Id: Ia2467a52e54c9688c3c1752e1fc00f5b37bbfeeb Reviewed-on: https://go-review.googlesource.com/32434 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Austin Clements authored
Idle GC workers trigger whenever there's a GC running and the scheduler doesn't find any other work. However, they currently run for a full scheduler quantum (~10ms) once started. This is really bad for event-driven applications, where work may come in on the network hundreds of times during that window. In the go-gcbench rpc benchmark, this is bad enough to often cause effective STWs where all Ps are in the idle worker. When this happens, we don't even poll the network any more (except for the background 10ms poll in sysmon), so we don't even know there's more work to do. Fix this by making idle workers check with the scheduler roughly every 100 µs to see if there's any higher-priority work the P should be doing. This check includes polling the network for incoming work. Fixes #16528. Change-Id: I6f62ebf6d36a92368da9891bafbbfd609b9bd003 Reviewed-on: https://go-review.googlesource.com/32433 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
- 19 Nov, 2016 1 commit
-
-
Ian Lance Taylor authored
Use an explicit ./ to make sure we link against the libgo.so we just built, not some other libgo.so that the compiler or linker may decide to seek out. Fixes #17986. Change-Id: Id23f6c95aa2b52f4f42c1b6dac45482c22b4290d Reviewed-on: https://go-review.googlesource.com/33413 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 18 Nov, 2016 10 commits
-
-
Robert Griesemer authored
Also: handle version "v2" of export data format. Fixes #17981. Change-Id: I8042ce18c4a27c70cc1ede675daca019b047bcf3 Reviewed-on: https://go-review.googlesource.com/33412Reviewed-by:
-
Keith Randall authored
So we can merge cover profiles from multiple runs. Change-Id: I1bf921e2b02063a2a62b35d21a6823062d10e5d0 Reviewed-on: https://go-review.googlesource.com/23831Reviewed-by:
Rob Pike <r@golang.org>
-
Robert Griesemer authored
This matches what we already do for switch statements and makes this large section more visibly organized. No other changes besides introducing the titles. Fixes #4486. Change-Id: I73f274e4fdd27c6cfeaed79090b4553e57a9c479 Reviewed-on: https://go-review.googlesource.com/33410Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Austin Clements authored
Currently, trace processing interleaves state/statistics updates and emitting trace viewer objects. As a result, if events are being filtered, either by time or by goroutines, we'll miss those state/statistics updates. At best, this leads to bad statistics; however, since we're now strictly checking G state transitions, it usually leads to a failure to process the trace if there is any filtering. Fix this by separating state updates from emitting trace object. State updates are done before filtering, so we always have correct state information and statistics. Trace objects are only emitted if we pass the filter. To determine when we need to emit trace counters, rather than duplicating the knowledge of which events might modify statistics, we keep track of the previously emitted counters and emit a trace counter object whenever these have changed. Fixes #17719. Change-Id: Ic66e3ddaef60d1acaaf2ff4c62baa5352799cf99 Reviewed-on: https://go-review.googlesource.com/32810Reviewed-by:
-
Robert Griesemer authored
(Revert of https://go-review.googlesource.com/#/c/32310/) For #16339. Fixes #17975. Change-Id: I36062703c423a81ea1c5b00f4429a4faf00b3782 Reviewed-on: https://go-review.googlesource.com/33365Reviewed-by:
-
Robert Griesemer authored
- organize examples better - add an example illustrating behavior if element type is a named pointer type - both compilers and go/types (per https://go-review.googlesource.com/33358) follow this now See the issue for detailed discussion. Fixes #17954. Change-Id: I8d90507ff2347d9493813f75b73233819880d2b4 Reviewed-on: https://go-review.googlesource.com/33361Reviewed-by:
-
Philip Hofer authored
The table of rewrites in ssa/cse is not sized appropriately for ssa IDs that are created during copying of selects into new blocks. Fixes #17918 Change-Id: I65fe86c6aab5efa679aa473aadc4ee6ea882cd41 Reviewed-on: https://go-review.googlesource.com/33240Reviewed-by:
David Chase <drchase@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Özgür Kesim authored
The existing implementation of text/template handles the option "missingkey=error" in an inconsitent manner: If the provided data is a nil-interface, no error is returned (despite the fact that no key can be found in it). This patch makes text/template return an error if "missingkey=error" is set and the provided data is a not a valid reflect.Value. Fixes #15356 Change-Id: Ia0a83da48652ecfaf31f18bdbd78cb21dbca1164 Reviewed-on: https://go-review.googlesource.com/31638Reviewed-by:
-
Cherry Zhang authored
Register of Phi input is allocated to the Phi. So if the Phi input is still live after Phi, we may need to use a spill. In this case, copy the Phi input to a spare register to avoid a spill. Originally targeted the code in issue #16187, and this CL indeed removes the spill, but doesn't seem to help on benchmark result. It may help in general, though. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.79s ± 1% 2.76s ± 0% -1.33% (p=0.000 n=10+10) Fannkuch11-12 3.02s ± 0% 3.14s ± 0% +3.99% (p=0.000 n=10+10) FmtFprintfEmpty-12 51.2ns ± 0% 51.4ns ± 3% ~ (p=0.368 n=8+10) FmtFprintfString-12 145ns ± 0% 144ns ± 0% -0.69% (p=0.000 n=6+9) FmtFprintfInt-12 127ns ± 1% 124ns ± 1% -2.79% (p=0.000 n=10+9) FmtFprintfIntInt-12 186ns ± 0% 184ns ± 0% -1.34% (p=0.000 n=10+9) FmtFprintfPrefixedInt-12 196ns ± 0% 194ns ± 0% -0.97% (p=0.000 n=9+9) FmtFprintfFloat-12 293ns ± 2% 287ns ± 0% -2.00% (p=0.000 n=10+9) FmtManyArgs-12 847ns ± 1% 829ns ± 0% -2.17% (p=0.000 n=10+7) GobDecode-12 7.17ms ± 0% 7.18ms ± 0% ~ (p=0.123 n=10+10) GobEncode-12 6.08ms ± 1% 6.08ms ± 0% ~ (p=0.497 n=10+9) Gzip-12 277ms ± 1% 275ms ± 1% -0.47% (p=0.028 n=10+9) Gunzip-12 39.1ms ± 2% 38.2ms ± 1% -2.20% (p=0.000 n=10+9) HTTPClientServer-12 90.9µs ± 4% 87.7µs ± 2% -3.51% (p=0.001 n=9+10) JSONEncode-12 17.3ms ± 1% 16.5ms ± 0% -5.02% (p=0.000 n=9+9) JSONDecode-12 54.6ms ± 1% 54.1ms ± 0% -0.99% (p=0.000 n=9+9) Mandelbrot200-12 4.45ms ± 0% 4.45ms ± 0% -0.02% (p=0.006 n=8+9) GoParse-12 3.44ms ± 0% 3.48ms ± 1% +0.95% (p=0.000 n=10+10) RegexpMatchEasy0_32-12 84.9ns ± 0% 85.0ns ± 0% ~ (p=0.241 n=8+8) RegexpMatchEasy0_1K-12 867ns ± 3% 915ns ±11% +5.55% (p=0.037 n=10+10) RegexpMatchEasy1_32-12 82.7ns ± 5% 83.9ns ± 4% ~ (p=0.161 n=9+10) RegexpMatchEasy1_1K-12 361ns ± 1% 363ns ± 0% ~ (p=0.098 n=10+8) RegexpMatchMedium_32-12 126ns ± 0% 126ns ± 1% ~ (p=0.549 n=8+10) RegexpMatchMedium_1K-12 38.8µs ± 0% 39.1µs ± 0% +0.67% (p=0.000 n=9+8) RegexpMatchHard_32-12 1.95µs ± 0% 1.96µs ± 0% +0.43% (p=0.000 n=9+9) RegexpMatchHard_1K-12 59.0µs ± 0% 59.1µs ± 0% +0.27% (p=0.000 n=10+9) Revcomp-12 436ms ± 1% 431ms ± 1% -1.19% (p=0.005 n=10+10) Template-12 56.7ms ± 1% 57.1ms ± 1% +0.71% (p=0.001 n=10+9) TimeParse-12 312ns ± 0% 310ns ± 0% -0.80% (p=0.000 n=10+9) TimeFormat-12 336ns ± 0% 332ns ± 0% -1.19% (p=0.000 n=8+7) [Geo mean] 59.2µs 58.9µs -0.42% On PPC64: name old time/op new time/op delta BinaryTree17-2 4.67s ± 2% 4.71s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-2 3.92s ± 1% 3.94s ± 0% +0.46% (p=0.032 n=5+5) FmtFprintfEmpty-2 122ns ± 0% 120ns ± 2% -1.80% (p=0.016 n=4+5) FmtFprintfString-2 305ns ± 1% 299ns ± 1% -1.84% (p=0.008 n=5+5) FmtFprintfInt-2 243ns ± 0% 241ns ± 1% -0.66% (p=0.016 n=4+5) FmtFprintfIntInt-2 361ns ± 1% 356ns ± 1% -1.49% (p=0.016 n=5+5) FmtFprintfPrefixedInt-2 355ns ± 1% 357ns ± 1% ~ (p=0.333 n=5+5) FmtFprintfFloat-2 502ns ± 2% 498ns ± 1% ~ (p=0.151 n=5+5) FmtManyArgs-2 1.55µs ± 2% 1.59µs ± 1% +2.52% (p=0.008 n=5+5) GobDecode-2 13.0ms ± 1% 13.0ms ± 1% ~ (p=0.841 n=5+5) GobEncode-2 11.8ms ± 1% 11.8ms ± 1% ~ (p=0.690 n=5+5) Gzip-2 499ms ± 1% 503ms ± 0% ~ (p=0.421 n=5+5) Gunzip-2 86.5ms ± 0% 86.4ms ± 1% ~ (p=0.841 n=5+5) HTTPClientServer-2 68.2µs ± 2% 69.6µs ± 3% ~ (p=0.151 n=5+5) JSONEncode-2 39.0ms ± 1% 37.2ms ± 1% -4.65% (p=0.008 n=5+5) JSONDecode-2 122ms ± 1% 126ms ± 1% +2.63% (p=0.008 n=5+5) Mandelbrot200-2 6.08ms ± 1% 5.89ms ± 1% -3.06% (p=0.008 n=5+5) GoParse-2 5.95ms ± 2% 5.98ms ± 1% ~ (p=0.421 n=5+5) RegexpMatchEasy0_32-2 331ns ± 1% 328ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchEasy0_1K-2 1.45µs ± 0% 1.47µs ± 0% +1.13% (p=0.008 n=5+5) RegexpMatchEasy1_32-2 359ns ± 0% 353ns ± 0% -1.84% (p=0.008 n=5+5) RegexpMatchEasy1_1K-2 1.79µs ± 0% 1.81µs ± 1% +1.16% (p=0.008 n=5+5) RegexpMatchMedium_32-2 420ns ± 2% 413ns ± 0% -1.72% (p=0.008 n=5+5) RegexpMatchMedium_1K-2 70.2µs ± 1% 69.5µs ± 1% -1.09% (p=0.032 n=5+5) RegexpMatchHard_32-2 3.87µs ± 1% 3.65µs ± 0% -5.86% (p=0.008 n=5+5) RegexpMatchHard_1K-2 111µs ± 0% 105µs ± 0% -5.49% (p=0.016 n=5+4) Revcomp-2 1.00s ± 1% 1.01s ± 2% ~ (p=0.151 n=5+5) Template-2 113ms ± 1% 113ms ± 2% ~ (p=0.841 n=5+5) TimeParse-2 555ns ± 0% 550ns ± 1% -0.87% (p=0.032 n=5+5) TimeFormat-2 736ns ± 1% 704ns ± 1% -4.35% (p=0.008 n=5+5) [Geo mean] 120µs 119µs -0.77% Reduce "spilled value remains" by 0.6% in cmd/go on AMD64. Change-Id: If655df343b0f30d1a49ab1ab644f10c698b96f3e Reviewed-on: https://go-review.googlesource.com/32442 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Elias Naur authored
Before this CL, Go programs in c-archive or c-shared buildmodes would not handle SIGPIPE. That leads to surprising behaviour where writes on a closed pipe or socket would raise SIGPIPE and terminate the program. This CL changes the Go runtime to handle SIGPIPE regardless of buildmode. In addition, SIGPIPE from non-Go code is forwarded. Fixes #17393 Updates #16760 Change-Id: I155e82020a03a5cdc627a147c27da395662c3fe8 Reviewed-on: https://go-review.googlesource.com/32796 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
