- 11 Apr, 2015 1 commit
-
-
Michael Hudson-Doyle authored
Jumping to an offset past a symbol isn't something that is really supported by dynamic linkers, so do it by hand. Change-Id: Ifff8834c6cdfa3d521ebd8479d2e93906df9b258 Reviewed-on: https://go-review.googlesource.com/8238Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
- 10 Apr, 2015 24 commits
-
-
Michael Hudson-Doyle authored
Skip the test when there is no .gosymtab section in the executable rather than crashing. Change-Id: Ieb3df07e307f50c33cdafab38f9b5d1ac0e55c04 Reviewed-on: https://go-review.googlesource.com/5110Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Ian Lance Taylor authored
Change-Id: I353ff7eb35b066a1a2693c087c9876adac8e3fd0 Reviewed-on: https://go-review.googlesource.com/8763Reviewed-by:
-
Shenghou Ma authored
Change-Id: I8d17e2b0fbc529ca7958c75222964a5e419aa3db Reviewed-on: https://go-review.googlesource.com/8717Reviewed-by:
-
Derek Buitenhuis authored
A similar fix was applied in 54568685 but another instance of 'pc' was missed. Also adds a test for the goroutine gdb command. It currently uses goroutine 2 for the test, since goroutine 1 has its stack pointer set to 0 for some reason. Change-Id: I53ca22be6952f03a862edbdebd9b5c292e0853ae Reviewed-on: https://go-review.googlesource.com/8729 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Rob Pike authored
Change-Id: I9e8a0dc152ef9403ff5ece0c161bda3a2f4448a8 Reviewed-on: https://go-review.googlesource.com/8760Reviewed-by:
Rob Pike <r@golang.org>
-
Caleb Spare authored
This is a version of Time.Format that doesn't require allocation. This is an updated version of 0af302f5 submitted by @bradfitz which was later rolled back. Fixes #5192 Updates #5195 Change-Id: I4e6255bee1cf3914a6cc8d9d2a881cfeb273c08e Reviewed-on: https://go-review.googlesource.com/1760Reviewed-by:
-
Dmitry Vyukov authored
Now that getg is an intrinsic, more runtime functions gets inlined (in particular, LockOSThread). Runtime code gets race instrumented after inlining into other packages. This can lead to false positives, as race detector ignores all internal synchronization in runtime. Inling of LockOSThread lead to false race reports on m contents. See the issue for an example. Fixes #10380 Change-Id: Ic9b760b53c28c2350bc54a5d4677fcd1c1f86e5f Reviewed-on: https://go-review.googlesource.com/8690Reviewed-by:
-
Austin Clements authored
Currently, when allocation reaches the concurrent GC trigger size, we start the concurrent collector by ready'ing its G. This simply puts it on the end of the P's run queue, which means we may not actually start GC for some time as the current G continues to run and then the P drains other Gs already on its run queue. Since the mutator can continue to allocate, the heap can potentially be much larger than we intended by the time GC actually starts. Furthermore, how much larger is difficult to predict since it depends on the scheduler. Fix this by preempting the current G and switching directly to the concurrent GC G as soon as we reach the trigger heap size. On the garbage benchmark from the benchmarks subrepo with GOMAXPROCS=4, this reduces the time from triggering the GC to the beginning of sweep termination by 10 to 30 milliseconds, which reduces allocation after the trigger by up to 10MB (a large fraction of the 64MB live heap the benchmark tries to maintain). One other known source of delay before we "really" start GC is the sweep finalization performed before sweep termination. This has similar negative effects on heap size and predictability, but is an orthogonal problem. This change adds a TODO for this. Change-Id: I8bae98cb43685c1bf353ff55868e4647e3743c47 Reviewed-on: https://go-review.googlesource.com/8513Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
These were appropriate for STW GC, since it interrupted the allocating Goroutine, but don't apply to concurrent GC, which runs on its own Goroutine. Forced GC is still STW, but it makes sense to attribute the GC to the goroutine that called runtime.GC(). Change-Id: If12418ca66dc7e53b8b16025af4e03adb5d9577e Reviewed-on: https://go-review.googlesource.com/8715Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
-
Austin Clements authored
Currently, GC disables preemption between the traceGCStart and traceGCDone, so it never moves Ps. Consequently, the trace verifier attaches information about GC to its per-P state and will fail if GC starts on one P and ends on another. GC will soon be preemptible and may end on a different P than it began. Hence, this change lifts this per-P verifier state to global state. Change-Id: I82256e2baab1ff3c4453fec312079018423b4b51 Reviewed-on: https://go-review.googlesource.com/8714Reviewed-by:
-
Austin Clements authored
exitsyscallfast checks for freezetheworld, but does so only by checking if stopwait is positive. This can also happen during stoptheworld, which is harmless, but confusing. Shortly, it will be important that we get to the p.status cas even if stopwait is set. Hence, make this test more specific so it only triggers with freezetheworld and not other uses of stopwait. Change-Id: Ibb722cd8360c3ed5a9654482519e3ceb87a8274d Reviewed-on: https://go-review.googlesource.com/8205Reviewed-by:
-
Austin Clements authored
Currently, the only way to know the Go type of an attribute of some DWARF attribute class was to read the dwarf package code (or experiment). This makes it hard to go from the DWARF specification to writing code that uses the dwarf package. Fix this by adding a table to the documentation comment of the Field type that gives the correspondence between DWARF attribute classes and Go types. Change-Id: I57c678a551fa1eb46f8207085d5a53d44985e3e7 Reviewed-on: https://go-review.googlesource.com/7280Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Robert Griesemer authored
The existing code used ints for the (slow) decimal conversion and assumed that they were 32bit wide. This change uses uints and the appropriate width (32 or 64bit) depending on platform. The performance difference is in the noise for the usual (optimized) case which does not use the slow path conversion: benchmark old ns/op new ns/op delta BenchmarkFormatFloatDecimal 298 299 +0.34% BenchmarkFormatFloat 388 392 +1.03% BenchmarkFormatFloatExp 365 364 -0.27% BenchmarkFormatFloatNegExp 364 362 -0.55% BenchmarkFormatFloatBig 482 476 -1.24% BenchmarkAppendFloatDecimal 100 102 +2.00% BenchmarkAppendFloat 199 201 +1.01% BenchmarkAppendFloatExp 174 175 +0.57% BenchmarkAppendFloatNegExp 169 174 +2.96% BenchmarkAppendFloatBig 286 286 +0.00% BenchmarkAppendFloat32Integer 99.9 102 +2.10% BenchmarkAppendFloat32ExactFraction 161 164 +1.86% BenchmarkAppendFloat32Point 199 201 +1.01% BenchmarkAppendFloat32Exp 167 168 +0.60% BenchmarkAppendFloat32NegExp 163 169 +3.68% BenchmarkAppendFloat64Fixed1 137 134 -2.19% BenchmarkAppendFloat64Fixed2 144 146 +1.39% BenchmarkAppendFloat64Fixed3 138 140 +1.45% BenchmarkAppendFloat64Fixed4 144 145 +0.69% The performance difference is significant if the fast path conversion is explicitly turned off (ftoa.go:101): benchmark old ns/op new ns/op delta BenchmarkFormatFloatDecimal 459 427 -6.97% BenchmarkFormatFloat 1560 1180 -24.36% BenchmarkFormatFloatExp 5501 3128 -43.14% BenchmarkFormatFloatNegExp 24085 14360 -40.38% BenchmarkFormatFloatBig 1409 1081 -23.28% BenchmarkAppendFloatDecimal 248 226 -8.87% BenchmarkAppendFloat 1315 982 -25.32% BenchmarkAppendFloatExp 5274 2869 -45.60% BenchmarkAppendFloatNegExp 23905 14054 -41.21% BenchmarkAppendFloatBig 1194 860 -27.97% BenchmarkAppendFloat32Integer 167 175 +4.79% BenchmarkAppendFloat32ExactFraction 182 184 +1.10% BenchmarkAppendFloat32Point 556 564 +1.44% BenchmarkAppendFloat32Exp 1134 918 -19.05% BenchmarkAppendFloat32NegExp 2679 1801 -32.77% BenchmarkAppendFloat64Fixed1 274 238 -13.14% BenchmarkAppendFloat64Fixed2 494 368 -25.51% BenchmarkAppendFloat64Fixed3 1833 1008 -45.01% BenchmarkAppendFloat64Fixed4 6133 3596 -41.37% Change-Id: I829b8abcca882b1c10d8ae421d3249597c31f3c9 Reviewed-on: https://go-review.googlesource.com/3811Reviewed-by:
-
Dmitry Vyukov authored
Fix tracing of syscall exit after: https://go-review.googlesource.com/#/c/7504/ Change-Id: Idcde2aa826d2b9a05d0a90a80242b6bfa78846ab Reviewed-on: https://go-review.googlesource.com/8728Reviewed-by:
-
Dmitry Vyukov authored
Fixes #10378 This is clumsy, but currently cover tool fails as: $ go test -run=none -cover syscall syscall_linux_amd64.go:15: can only use //go:noescape with external func implementations FAIL syscall [build failed] This happens because cover tool mishandles //go: comments. r and gri said that fixing cover is infeasible due to go/ast limitations. So at least fix the offending code so that coverage works. This come up in context of coverage-guided fuzzing which works best with program-wide coverage. Change-Id: I142e5774c9f326ed38cb202693bd4edae93879ba Reviewed-on: https://go-review.googlesource.com/8723Reviewed-by:
-
Dmitry Vyukov authored
The flag updates error annotations in test files from actual compiler output. This is useful when doing compiler changes that add/remove/change lots of errors, or when adding lots of new tests. Also I noticed at least 2 cases where annotation were sub-optimal: 1. The annotation was "leaking param p" when the actual error is "leaking param p to result ~r1". 2. The annotation was "leaking param m" when the actual errors are "leaking param m" and "leaking param mv1". For now it works only for errorcheck mode. Also, apply the update to escape and liveness tests. Some files have gccgo-specific errors of the form "gc error|gccgo error", so it is risky to run update on all files. Gccgo-specific error does not necessary contain '|', it can be just truncated. Change-Id: Iaaae767f859dcb8321a8cb4970b2b70969e8a345 Reviewed-on: https://go-review.googlesource.com/5310 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Paul Marks authored
Remove the "netaddr" type, which ambiguously represented either one address, or a list of addresses. Instead, use "addrList" wherever multiple addresses are supported. The "first" method returns the first address matching some condition (e.g. "is it IPv4?"), primarily to support legacy code that can't handle multiple addresses. The "partition" method splits an addrList into two categories, as defined by some strategy function. This is useful for implementing Happy Eyeballs, and similar two-channel algorithms. Finally, internetAddrList (formerly resolveInternetAddr) no longer mangles the ordering defined by getaddrinfo. In the future, this may be used by a sequential Dial implementation. Updates #8453, #8455. Change-Id: I7375f4c34481580ab40e31d33002a4073a0474f3 Reviewed-on: https://go-review.googlesource.com/8360Reviewed-by:
Mikio Hara <mikioh.mikioh@gmail.com> Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dave Cheney authored
Update #9855 In preparation for introducing direct use of a zero register on platforms that support it, take the opportunity to clean up Componentgen a bit. Change-Id: I120ce1ffcca8c4f7603bfe76bfa1aedd27ebb4d2 Reviewed-on: https://go-review.googlesource.com/8691 Run-TryBot: Dave Cheney <dave@cheney.net> Reviewed-by:
Minux Ma <minux@golang.org>
-
Michael Hudson-Doyle authored
'themoduledata' doesn't really make sense now we support multiple moduledata objects. Change-Id: I8263045d8f62a42cb523502b37289b0fba054f62 Reviewed-on: https://go-review.googlesource.com/8521Reviewed-by:
-
Daniel Theophanes authored
If GOBIN is not empty the build moves the go executable to a new path. When this test runs it fails to find the go cmd in the GOROOT. Change-Id: I100def0fbcb9691b13776f795b1d1725e36d8102 Reviewed-on: https://go-review.googlesource.com/8735Reviewed-by:
-
Michael Hudson-Doyle authored
This changes all the places that consult themoduledata to consult a linked list of moduledata objects, as will be necessary for -linkshared to work. Obviously, as there is as yet no way of adding moduledata objects to this list, all this change achieves right now is wasting a few instructions here and there. Change-Id: I397af7f60d0849b76aaccedf72238fe664867051 Reviewed-on: https://go-review.googlesource.com/8231Reviewed-by:
-
Michael Hudson-Doyle authored
Modelled somewhat on the -race support. Change-Id: I137037addfc76341f7deb216776fdd18e9af9fe5 Reviewed-on: https://go-review.googlesource.com/8680Reviewed-by:
-
Michael Hudson-Doyle authored
Change-Id: I49862e177045369d6c94d6a58afbdace4f13cc96 Reviewed-on: https://go-review.googlesource.com/8237Reviewed-by:
-
Josh Bleecher Snyder authored
Broken by CL 8541. Change-Id: Ie2e89a22b91748e82f7bc4723660a24ed4135687 Reviewed-on: https://go-review.googlesource.com/8734Reviewed-by:
-
- 09 Apr, 2015 15 commits
-
-
Austin Clements authored
Currently, the initial heap size reported in the gctrace line is the heap_live right before sweep termination. However, we triggered GC when heap_live reached next_gc, and there may have been significant allocation between that point and the beginning of sweep termination. Ideally these would be essentially the same, but currently there's scheduler delay when readying the GC goroutine as well as delay from background sweep finalization. We should fix this delay, but in the mean time, to give the user a better idea of how much the heap grew during the whole of garbage collection, report the trigger rather than what the heap size happened to be after the garbage collector finished rolling out of bed. This will also be more useful for heap growth plots. Change-Id: I08476b9fbcfb2de90592405e9c9f434dfb9eb1f8 Reviewed-on: https://go-review.googlesource.com/8512Reviewed-by:
-
Robert Griesemer authored
Change-Id: Ia0944e7b47193465d3ec37fc8dc46dea9b5dcc6b Reviewed-on: https://go-review.googlesource.com/8710Reviewed-by:
-
David Crawshaw authored
According to Go execution modes, a Go program compiled with -buildmode=c-archive has a main function, but it is ignored on run. This gives the runtime the information it needs not to run the main. I have this working with pending linker changes on darwin/amd64. Change-Id: I49bd7d65aa619ec847c464a872afa5deea7d4d30 Reviewed-on: https://go-review.googlesource.com/8701Reviewed-by:
-
Rob Pike authored
Print("") was printing a header but no line. Fixes #9665. Change-Id: Iac783187786065e1389ad6e8d7ef02c579ed7bd8 Reviewed-on: https://go-review.googlesource.com/8665Reviewed-by: -
Rob Pike authored
Also unify the tests where possible to make it easy to add more. Fixes #10273. Change-Id: Idfa4f4a5dcaa05974066bafe17bed6cdd2ebedb7 Reviewed-on: https://go-review.googlesource.com/8662Reviewed-by:
-
Dave Cheney authored
Add arm64 assembly implementation of runtime.cmpstring and bytes.Compare. benchmark old ns/op new ns/op delta BenchmarkCompareBytesEqual 98.0 27.5 -71.94% BenchmarkCompareBytesToNil 9.38 10.0 +6.61% BenchmarkCompareBytesEmpty 13.3 10.0 -24.81% BenchmarkCompareBytesIdentical 98.0 27.5 -71.94% BenchmarkCompareBytesSameLength 43.3 16.3 -62.36% BenchmarkCompareBytesDifferentLength 43.4 16.3 -62.44% BenchmarkCompareBytesBigUnaligned 6979680 1360979 -80.50% BenchmarkCompareBytesBig 6915995 1381979 -80.02% BenchmarkCompareBytesBigIdentical 6781440 1327304 -80.43% benchmark old MB/s new MB/s speedup BenchmarkCompareBytesBigUnaligned 150.23 770.46 5.13x BenchmarkCompareBytesBig 151.62 758.76 5.00x BenchmarkCompareBytesBigIdentical 154.63 790.01 5.11x * note, the machine we are benchmarking on has some issues. What is clear is compared to a few days ago the old MB/s value has increased from ~115 to 150. I'm less certain about the new MB/s number, which used to be close to 1Gb/s. Change-Id: I4f31b2c7a06296e13912aacc958525632cb0450d Reviewed-on: https://go-review.googlesource.com/8541Reviewed-by:
Aram Hăvărneanu <aram@mgk.ro> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Anthony Martin authored
Change-Id: I98b172181c2fd85aa385341e28bc661dbc274252 Reviewed-on: https://go-review.googlesource.com/2167 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
Daniel Morsing authored
There was a logical race in Transport.RoundTrip where a roundtrip with a pending response would race with the channel for the connection closing. This usually happened for responses with connection: close and no body. We handled this race by reading the close channel, setting a timer for 100ms and if no response was returned before then, we would then return an error. This put a lower bound on how fast a connection could fail. We couldn't fail a request faster than 100ms. Reordering the channel operations gets rid of the logical race. If the readLoop causes the connection to be closed, it would have put its response into the return channel already and we can fetch it with a non-blocking receive. Change-Id: Idf09e48d7a0453d7de0120d3055d0ce5893a5428 Reviewed-on: https://go-review.googlesource.com/1787Reviewed-by:
-
Billie H. Cleek authored
The API call will fail when Bitbucket repositories are private. In that case, probe for the repository using vcsCmd.ping. Fixes #5375 Change-Id: Ia604ecf9014805579dfda4b5c8e627a52783d56e Reviewed-on: https://go-review.googlesource.com/1910Reviewed-by: -
Dmitry Vyukov authored
Fixes #10353 See test/escape2.go:issue10353. Previously new(int) did not escape to heap, and so heap-allcated closure was referencing a stack var. This breaks the invariant that heap must not contain pointers to stack. Look at the following program: package main func main() { foo(new(int)) bar(new(int)) } func foo(x *int) func() { return func() { println(*x) } } // Models what foo effectively does. func bar(x *int) *C { return &C{x} } type C struct { x *int } Without this patch escape analysis works as follows: $ go build -gcflags="-m -m -m -l" esc.go escflood:1: dst ~r1 scope:foo[0] escwalk: level:0 depth:0 func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:9: func literal escapes to heap escwalk: level:0 depth:1 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:8: leaking param: x to result ~r1 escflood:2: dst ~r1 scope:bar[0] escwalk: level:0 depth:0 &C literal( l(15) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:15: &C literal escapes to heap escwalk: level:-1 depth:1 &C literal( l(15)) scope:bar[0] escwalk: level:-1 depth:2 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:14: leaking param: x /tmp/live2.go:5: new(int) escapes to heap /tmp/live2.go:4: main new(int) does not escape new(int) does not escape while being captured by the closure. With this patch escape analysis of foo and bar works similarly: $ go build -gcflags="-m -m -m -l" esc.go escflood:1: dst ~r1 scope:foo[0] escwalk: level:0 depth:0 &(func literal)( l(9)) scope:foo[0] escwalk: level:-1 depth:1 func literal( l(9) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:9: func literal escapes to heap escwalk: level:-1 depth:2 x( l(8) class(PPARAM) f(1) esc(no) ld(1)) scope:foo[1] /tmp/live2.go:8: leaking param: x escflood:2: dst ~r1 scope:bar[0] escwalk: level:0 depth:0 &C literal( l(15) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:15: &C literal escapes to heap escwalk: level:-1 depth:1 &C literal( l(15)) scope:bar[0] escwalk: level:-1 depth:2 x( l(14) class(PPARAM) f(1) esc(no) ld(1)) scope:bar[1] /tmp/live2.go:14: leaking param: x /tmp/live2.go:4: new(int) escapes to heap /tmp/live2.go:5: new(int) escapes to heap Change-Id: Ifd14b7ae3fc11820e3b5eb31eb07f35a22ed0932 Reviewed-on: https://go-review.googlesource.com/8408Reviewed-by: -
Alex Brainman authored
Mainly it is simple copy. But I had to change amd64 lastcontinuehandler return value from uint32 to int32. I don't remember how it happened to be uint32, but new int32 is matching better with Windows documentation (LONG). I don't think it matters one way or the others. Change-Id: I6935224a2470ad6301e27590f2baa86c13bbe8d5 Reviewed-on: https://go-review.googlesource.com/8686Reviewed-by:
-
Matthew Brennan authored
This update makes maxBacktrackLen return 0 if len(prog.Inst) > maxBacktrackProg. This prevents an attempt to backtrack against a nil bitstate. Fixes #10319 Change-Id: Icdbeb2392782ccf66f9d0a70ea57af22fb93f01b Reviewed-on: https://go-review.googlesource.com/8473Reviewed-by:
-
Mikio Hara authored
When making a request to an IPv6 address with a zone identifier, for exmaple [fe80::1%en0], RFC 6874 says HTTP clients must remove the zone identifier "%en0" before writing the request for security reason. This change removes any IPv6 zone identifer attached to URI in the Host header field in requests. Fixes #9544. Change-Id: I7406bd0aa961d260d96f1f887c2e45854e921452 Reviewed-on: https://go-review.googlesource.com/3111Reviewed-by:
-
Daniel Theophanes authored
Rename now uses MoveFileEx which was previously not available to use because it is not supported on Windows 2000. Change-Id: I583d029c4467c9be6d1574a790c423559b441e87 Reviewed-on: https://go-review.googlesource.com/6140Reviewed-by:
-
Dave Cheney authored
Add support for arm64 four operand conditional instructions. Superceedes CL 8405. Change-Id: I12da8f4822938feec400bbcc426eeaf884536135 Reviewed-on: https://go-review.googlesource.com/8638Reviewed-by:
-
