- 21 May, 2015 3 commits
-
-
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>
-
Rick Hudson authored
During development we ran with monitoring code turned on by default. This CL turns the work buffer monitoring off. Performance change on most go1 benchmarks is small or insignificant. name old mean new mean delta BinaryTree17 3.35s × (0.99,1.01) 3.35s × (0.99,1.01) ~ (p=0.841 n=5+5) Fannkuch11 2.59s × (1.00,1.01) 2.55s × (1.00,1.00) -1.65% (p=0.008 n=5+5) FmtFprintfEmpty 52.5ns × (0.99,1.02) 53.2ns × (0.98,1.01) ~ (p=0.063 n=5+5) FmtFprintfString 181ns × (1.00,1.00) 180ns × (1.00,1.00) -0.55% (p=0.029 n=4+4) FmtFprintfInt 176ns × (1.00,1.01) 174ns × (1.00,1.00) -0.91% (p=0.000 n=5+4) FmtFprintfIntInt 298ns × (1.00,1.00) 299ns × (1.00,1.00) ~ (p=0.143 n=4+4) FmtFprintfPrefixedInt 250ns × (1.00,1.01) 246ns × (1.00,1.00) -1.68% (p=0.000 n=5+4) FmtFprintfFloat 340ns × (1.00,1.00) 340ns × (1.00,1.01) ~ (p=0.643 n=5+5) FmtManyArgs 1.16µs × (1.00,1.00) 1.15µs × (1.00,1.00) -0.47% (p=0.016 n=5+5) GobDecode 9.22ms × (1.00,1.00) 9.23ms × (1.00,1.00) ~ (p=0.841 n=5+5) GobEncode 7.00ms × (1.00,1.01) 7.09ms × (0.99,1.01) +1.26% (p=0.016 n=5+5) Gzip 387ms × (1.00,1.00) 389ms × (0.99,1.02) ~ (p=1.000 n=5+5) Gunzip 97.8ms × (1.00,1.00) 98.3ms × (1.00,1.00) +0.51% (p=0.016 n=5+4) HTTPClientServer 52.6µs × (1.00,1.01) 52.7µs × (1.00,1.01) ~ (p=1.000 n=5+5) JSONEncode 18.0ms × (0.99,1.02) 17.9ms × (1.00,1.00) ~ (p=0.310 n=5+5) JSONDecode 64.8ms × (0.99,1.02) 63.6ms × (1.00,1.00) -1.94% (p=0.008 n=5+5) Mandelbrot200 4.05ms × (1.00,1.00) 4.05ms × (1.00,1.00) ~ (p=0.421 n=5+5) GoParse 3.86ms × (1.00,1.01) 3.84ms × (0.99,1.01) ~ (p=0.421 n=5+5) RegexpMatchEasy0_32 101ns × (1.00,1.00) 102ns × (0.99,1.02) ~ (p=0.238 n=4+5) RegexpMatchEasy0_1K 346ns × (1.00,1.01) 345ns × (1.00,1.00) ~ (p=0.333 n=5+4) RegexpMatchEasy1_32 87.3ns × (0.99,1.02) 87.4ns × (1.00,1.00) ~ (p=0.190 n=5+4) RegexpMatchEasy1_1K 520ns × (1.00,1.00) 520ns × (1.00,1.01) ~ (p=1.000 n=4+5) RegexpMatchMedium_32 143ns × (1.00,1.00) 142ns × (1.00,1.00) -0.70% (p=0.029 n=4+4) RegexpMatchMedium_1K 43.2µs × (1.00,1.01) 43.2µs × (1.00,1.00) ~ (p=0.841 n=5+5) RegexpMatchHard_32 2.24µs × (1.00,1.01) 2.23µs × (1.00,1.01) -0.63% (p=0.048 n=5+5) RegexpMatchHard_1K 68.7µs × (1.00,1.00) 68.3µs × (1.00,1.00) -0.56% (p=0.008 n=5+5) Revcomp 577ms × (1.00,1.01) 579ms × (1.00,1.00) ~ (p=0.151 n=5+5) Template 74.9ms × (1.00,1.00) 76.5ms × (1.00,1.00) +2.11% (p=0.008 n=5+5) TimeParse 359ns × (1.00,1.00) 362ns × (1.00,1.00) +0.72% (p=0.008 n=5+5) TimeFormat 369ns × (1.00,1.00) 371ns × (1.00,1.01) ~ (p=0.071 n=5+5) Change-Id: I4206a3f77a3d1450966b7a62ea7597aec44cb72f Reviewed-on: https://go-review.googlesource.com/10294Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Austin Clements authored
Currently runtime.callers invokes gentraceback with the pc and sp of the G it is called from, but always passes g0 even if it was called from a regular g. Right now this has no ill effects because runtime.callers does not use either callback argument or the _TraceJumpStack flag, but it makes the code fragile and will break some upcoming changes. Fix this by lifting the getg() call outside of the systemstack in runtime.callers. Change-Id: I4e1e927961c0e0cd4dcf28693be47df7bae9e122 Reviewed-on: https://go-review.googlesource.com/10292Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com> Reviewed-by: Rick Hudson <rlh@golang.org>
-
- 20 May, 2015 8 commits
-
-
Shenghou Ma authored
Fixes #10908. Change-Id: I5ac4bd90204bc230610dcced47ce5b2253e5a004 Reviewed-on: https://go-review.googlesource.com/10250Reviewed-by: Rob Pike <r@golang.org>
-
Mikio Hara authored
Also mentions golang.org/x/net/ipv4 and golang.org/x/net/ipv6. Change-Id: I653deac7a5e2b129237655a72d6c91207f1b1685 Reviewed-on: https://go-review.googlesource.com/9779Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Alan Donovan authored
Formerly it would return a BadExpr. This prevents partial syntax from being discarded, and makes the error recovery logic more consistent with other places where an identifier was expected but not found. + test Change-Id: I223c0c0589e7ceb7207ae951b8f71b9275a1eb73 Reviewed-on: https://go-review.googlesource.com/10269Reviewed-by: Robert Griesemer <gri@golang.org>
-
Rob Pike authored
An error in string slice offsets caused the loop to run forever if the first character in the argument was a period. Fixes #10833. Change-Id: Iefb6aac5cff8864fe93d08e2600cb07d82c6f6df Reviewed-on: https://go-review.googlesource.com/10285Reviewed-by: Russ Cox <rsc@golang.org>
-
Rick Hudson authored
This is dead code. If you want to quiesce the system the preferred way is to use forEachP(func(*p){}). Change-Id: Ic7677a5dd55e3639b99e78ddeb2c71dd1dd091fa Reviewed-on: https://go-review.googlesource.com/10267Reviewed-by: Austin Clements <austin@google.com>
-
Michael Hudson-Doyle authored
Makes little difference internally but makes go list output more useful. Change-Id: I1fa1f839107de08818427382b2aef8dc4d765b36 Reviewed-on: https://go-review.googlesource.com/10192Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
On Windows, we need to make sure that the node under test has external connectivity. Fixes #10795. Change-Id: I99f2336180c7b56474fa90a4a6cdd5a6c4dd3805 Reviewed-on: https://go-review.googlesource.com/10006Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Fixes #10891. Change-Id: Ie432c9c5520ac29cea8fe6452628ec467567eea5 Reviewed-on: https://go-review.googlesource.com/10194Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 19 May, 2015 16 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>
-
Shenghou Ma authored
On my systems, ld -rpath sets DT_RUNPATH instead of DT_RPATH. Change-Id: I5047e795fb7ef9336f5fa13ba24bb6245c0b0582 Reviewed-on: https://go-review.googlesource.com/10260Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Shenghou Ma authored
386 is not affected because it doesn't use ginscmp. Fixes #10843. Change-Id: I1b3a133bd1e5fabc85236f15d060dbaa4c391cf3 Reviewed-on: https://go-review.googlesource.com/10116Reviewed-by: Russ Cox <rsc@golang.org>
-
Didier Spezia authored
In css, js, and html, the replacement operations are implemented by iterating on strings (rune by rune). The for/range statement is used. The length of the rune is required and added to the index to properly slice the string. This is potentially wrong because there is a discrepancy between the result of utf8.RuneLen and the increment of the index (set by the for/range statement). For invalid strings, utf8.RuneLen('\ufffd') == 3, while the index is incremented only by 1 byte. htmlReplacer triggers a panic at slicing time for some invalid strings. Use a more robust iteration mechanism based on utf8.DecodeRuneInString, and make sure the same pattern is used for all similar functions in this package. Fixes #10799 Change-Id: Ibad3857b2819435d9fa564f06fc2ca8774102841 Reviewed-on: https://go-review.googlesource.com/10105Reviewed-by: Rob Pike <r@golang.org>
-
Shenghou Ma authored
Change-Id: Ib6c121414c74f8a40eb87a52af8737502ce7216d Reviewed-on: https://go-review.googlesource.com/10265Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Austin Clements authored
Commit 9c9e36b3 pushed these errors down to where the write barriers are actually emitted, but forgot to remove the original error that was being pushed down. Change-Id: I751752a896e78fb9e63d69f88e7fb8d1ff5d344c Reviewed-on: https://go-review.googlesource.com/10264Reviewed-by: Russ Cox <rsc@golang.org>
-
Alexander Zolotov authored
The existing implementation executes `gofmt` binary from PATH environment variable on invocation `go fmt` command. Relying on PATH might lead to confusions for users with several Go installations. It's more appropriate to run `gofmt` from GOBIN (if defined) or GOROOT. Fixes #10755 Change-Id: I56d42a747319c766f2911508fab3994c3a366d12 Reviewed-on: https://go-review.googlesource.com/9900Reviewed-by: Rob Pike <r@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>
-
Russ Cox authored
Change-Id: I348223d0336e28d95b8e68d7653aa547acc7c9c3 Reviewed-on: https://go-review.googlesource.com/10262Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
Fixes #8745. Change-Id: Id0641e3c0f259812b41ed871e83c68740feb2b19 Reviewed-on: https://go-review.googlesource.com/10261Reviewed-by: Austin Clements <austin@google.com>
-
Rick Hudson authored
Prior to this CL whenever the GC marking was enabled and a P was looking for work we supplied a G to help the GC do its marking tasks. Once this G finished all the marking available it would release the P to find another available G. In the case where there was no work the P would drop into findrunnable which would execute the mark helper G which would immediately return and the P would drop into findrunnable again repeating the process. Since the P was always given a G to run it never blocks. This CL first checks if the GC mark helper G has available work and if not the P immediately falls through to its blocking logic. Fixes #10901 Change-Id: I94ac9646866ba64b7892af358888bc9950de23b5 Reviewed-on: https://go-review.googlesource.com/10189Reviewed-by: Austin Clements <austin@google.com>
-
Austin Clements authored
Currently setGCPercent sets heapminimum to heapminimum*GOGC/100. The real intent is to set heapminimum to a scaled multiple of a fixed default heap minimum, not to scale heapminimum based on its current value. This turns out to be okay because setGCPercent is only called once and heapminimum is initially set to this default heap minimum. However, the code as written is confusing, especially since setGCPercent is otherwise written so it could be called again to change GOGC. Fix this by introducing a defaultHeapMinimum constant and using this instead of the current value of heapminimum to compute the scaled heap minimum. As part of this, this commit improves the documentation on heapminimum. Change-Id: I4eb82c73dc2eb44a6e5a17c780a747a2e73d7493 Reviewed-on: https://go-review.googlesource.com/10181Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Addresses a problem reported on the mailing list. This will come up mainly in programs custom allocators that batch allocations, but it still helps in our programs, which mainly do not have such allocations. name old mean new mean delta BinaryTree17 5.95s × (0.97,1.03) 5.93s × (0.97,1.04) ~ (p=0.613) Fannkuch11 4.46s × (0.98,1.04) 4.33s × (0.99,1.01) -2.93% (p=0.000) FmtFprintfEmpty 86.6ns × (0.98,1.03) 86.8ns × (0.98,1.02) ~ (p=0.523) FmtFprintfString 290ns × (0.98,1.05) 287ns × (0.98,1.03) ~ (p=0.061) FmtFprintfInt 271ns × (0.98,1.04) 286ns × (0.99,1.01) +5.54% (p=0.000) FmtFprintfIntInt 495ns × (0.98,1.04) 489ns × (0.99,1.01) -1.24% (p=0.015) FmtFprintfPrefixedInt 391ns × (0.99,1.02) 407ns × (0.99,1.01) +4.00% (p=0.000) FmtFprintfFloat 578ns × (0.99,1.01) 559ns × (0.99,1.01) -3.35% (p=0.000) FmtManyArgs 1.96µs × (0.98,1.05) 1.94µs × (0.99,1.01) -1.33% (p=0.030) GobDecode 15.9ms × (0.97,1.05) 15.7ms × (0.99,1.01) -1.35% (p=0.044) GobEncode 11.4ms × (0.97,1.05) 11.3ms × (0.98,1.03) ~ (p=0.141) Gzip 658ms × (0.98,1.05) 648ms × (0.99,1.01) -1.59% (p=0.009) Gunzip 144ms × (0.99,1.03) 144ms × (0.99,1.01) ~ (p=0.867) HTTPClientServer 92.1µs × (0.97,1.05) 90.3µs × (0.99,1.01) -1.89% (p=0.005) JSONEncode 31.0ms × (0.96,1.07) 30.2ms × (0.98,1.03) -2.66% (p=0.001) JSONDecode 110ms × (0.97,1.04) 107ms × (0.99,1.01) -2.59% (p=0.000) Mandelbrot200 6.15ms × (0.98,1.04) 6.07ms × (0.99,1.02) -1.32% (p=0.045) GoParse 6.79ms × (0.97,1.04) 6.74ms × (0.97,1.04) ~ (p=0.242) RegexpMatchEasy0_32 158ns × (0.98,1.05) 155ns × (0.99,1.01) -1.64% (p=0.010) RegexpMatchEasy0_1K 548ns × (0.97,1.04) 540ns × (0.99,1.01) -1.34% (p=0.042) RegexpMatchEasy1_32 133ns × (0.97,1.04) 132ns × (0.97,1.05) ~ (p=0.466) RegexpMatchEasy1_1K 899ns × (0.96,1.05) 878ns × (0.99,1.01) -2.32% (p=0.002) RegexpMatchMedium_32 250ns × (0.96,1.03) 243ns × (0.99,1.01) -2.90% (p=0.000) RegexpMatchMedium_1K 73.4µs × (0.98,1.04) 73.0µs × (0.98,1.04) ~ (p=0.411) RegexpMatchHard_32 3.87µs × (0.97,1.07) 3.84µs × (0.98,1.04) ~ (p=0.273) RegexpMatchHard_1K 120µs × (0.97,1.08) 117µs × (0.99,1.01) -2.06% (p=0.010) Revcomp 940ms × (0.96,1.07) 924ms × (0.97,1.07) ~ (p=0.071) Template 128ms × (0.96,1.05) 128ms × (0.99,1.01) ~ (p=0.502) TimeParse 632ns × (0.96,1.07) 616ns × (0.99,1.01) -2.58% (p=0.001) TimeFormat 671ns × (0.97,1.06) 657ns × (0.99,1.02) -2.10% (p=0.002) In contrast to the one in test/bench/go1 (above), the binarytree program on the shootout site uses more goroutines, batches allocations, and sets GOMAXPROCS to runtime.NumCPU()*2. Using that version, before vs after: name old mean new mean delta BinaryTree20 18.6s × (0.96,1.05) 11.3s × (0.98,1.02) -39.46% (p=0.000) And Go 1.4 vs after: name old mean new mean delta BinaryTree20 13.0s × (0.97,1.02) 11.3s × (0.98,1.02) -13.21% (p=0.000) There is still a scheduling problem - the raw run times are hiding the fact that this chews up 2x the CPU - but we'll take care of that separately. Change-Id: I3f5da879b24ae73a0d06745381ffb88c3744948b Reviewed-on: https://go-review.googlesource.com/10220Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
Fixes #10897. Change-Id: I5c2d1f9d26333e2b2a0613ebf496daa465e07c24 Reviewed-on: https://go-review.googlesource.com/10221Reviewed-by: Austin Clements <austin@google.com>
-
Shenghou Ma authored
Fixes #10906. Change-Id: I7ae25a500df493c1e78183d69d89b3e2a64a0d1a Reviewed-on: https://go-review.googlesource.com/10223Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Aaron Jacobs authored
I think "the flag" was a typo, and the word "after" was repetitive. Change-Id: I81c034ca11a3a778ff1eb4b3af5b96bc525ab985 Reviewed-on: https://go-review.googlesource.com/10195Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 18 May, 2015 13 commits
-
-
Josh Bleecher Snyder authored
Rearrange Node fields to enable better struct packing. This reduces readability in favor of shrinking the size of Nodes. This reduces the size of Node from 328 to 312. This reduces the memory usage to compile the rotate tests by about 4.4%. No functional changes. Passes toolstash -cmp. Updates #9933. Change-Id: I2764c5847fb1635ddc898e2ee385d007d67f03c5 Reviewed-on: https://go-review.googlesource.com/10141Reviewed-by: Russ Cox <rsc@golang.org>
-
Josh Bleecher Snyder authored
Param will be converted from an anonymous to a named field in a subsequent, automated CL. Reduces Node size from 368 to 328. Reduces inuse_space on the rotate tests by about 3%. No functional changes. Passes toolstash -cmp. Updates #9933. Change-Id: I5867b00328abf17ee24aea6ca58876bae9d8bfed Reviewed-on: https://go-review.googlesource.com/10210Reviewed-by: Russ Cox <rsc@golang.org>
-
Josh Bleecher Snyder authored
Change-Id: Ifda5d84b28717986c93b63767298180a6d6236c0 Reviewed-on: https://go-review.googlesource.com/10140Reviewed-by: Russ Cox <rsc@golang.org>
-
Josh Bleecher Snyder authored
Funcdepth was already int32. Make Escloopdepth and Decldepth also int32 instead of int. No functional changes for non-absurd code. Passes toolstash -cmp. Change-Id: I47e145dd732b6a73cfcc6d45956df0dbccdcd999 Reviewed-on: https://go-review.googlesource.com/10129Reviewed-by: Russ Cox <rsc@golang.org>
-
Josh Bleecher Snyder authored
This is a duplicate of CL 9491. That CL broke the build due to pprof shortcomings and was reverted in CL 9565. CL 9623 fixed pprof, so this can go in again. Fixes #10659. Change-Id: If470fc90b3db2ade1d161b4417abd2f5c6c330b8 Reviewed-on: https://go-review.googlesource.com/10212Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Daniel Morsing authored
Fixes #10659. Change-Id: I22dc306ce6f398dd40010ac430928a718d67d466 Reviewed-on: https://go-review.googlesource.com/9623Reviewed-by: Russ Cox <rsc@golang.org>
-
Rob Pike authored
Better layout. Fixes #10859. The issue suggests rearranging so the comment comes out after the methods. I tried this and it looks good but it is less useful, since the stuff you're probably looking for - the methods - are scrolled away by the comment. The most important information should be last because that leaves it on your screen after the print if the output is long. Change-Id: I560f992601ccbe2293c347fa1b1018a3f5346c82 Reviewed-on: https://go-review.googlesource.com/10160Reviewed-by: Russ Cox <rsc@golang.org>
-
Michael Hudson-Doyle authored
And fix to work on filesystems with only 1s resolution. Fixes #10724 Change-Id: Ia07463f090b4290fc27f5953fa94186463d7afc7 Reviewed-on: https://go-review.googlesource.com/9768Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Fixes #10893. Change-Id: I8afeb55acda1e1c8e181379dbaf443716d63ded1 Reviewed-on: https://go-review.googlesource.com/10201Reviewed-by: Rob Pike <r@golang.org>
-
David Chase authored
Modified esc.go to allow slice literals (before append) to be non-escaping. Modified tests to account for changes in escape behavior and to also test the two cases that were previously not tested. Also minor cleanups to debug-printing within esc.go Allocation stats for running compiler ( cd src/html/template; for i in {1..5} ; do go tool 6g -memprofile=testzz.${i}.prof -memprofilerate=1 *.go ; go tool pprof -alloc_objects -text testzz.${i}.prof ; done ; ) before about 86k allocations after about 83k allocations Fixes #8972 Change-Id: Ib61dd70dc74adb40d6f6fdda6eaa4bf7d83481de Reviewed-on: https://go-review.googlesource.com/10118Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently, forEachP reuses the stopwait and stopnote fields from stopTheWorld to track how many Ps have not responded to the safe-point request and to sleep until all Ps have responded. It was assumed this was safe because both stopTheWorld and forEachP must occur under the worlsema and hence stopwait and stopnote cannot be used for both purposes simultaneously and callers could always determine the appropriate use based on sched.gcwaiting (which is only set by stopTheWorld). However, this is not the case, since it's possible for there to be a window between when an M observes that gcwaiting is set and when it checks stopwait during which stopwait could have changed meanings. When this happens, the M decrements stopwait and may wakeup stopnote, but does not otherwise participate in the forEachP protocol. As a result, stopwait is decremented too many times, so it may reach zero before all Ps have run the safe-point function, causing forEachP to wake up early. It will then either observe that some P has not run the safe-point function and panic with "P did not run fn", or the remaining P (or Ps) will run the safe-point function before it wakes up and it will observe that stopwait is negative and panic with "not stopped". Fix this problem by giving forEachP its own safePointWait and safePointNote fields. One known sequence of events that can cause this race is as follows. It involves three actors: G1 is running on M1 on P1. P1 has an empty run queue. G2/M2 is in a blocked syscall and has lost its P. (The details of this don't matter, it just needs to be in a position where it needs to grab an idle P.) GC just started on G3/M3/P3. (These aren't very involved, they just have to be separate from the other G's, M's, and P's.) 1. GC calls stopTheWorld(), which sets sched.gcwaiting to 1. Now G1/M1 begins to enter a syscall: 2. G1/M1 invokes reentersyscall, which sets the P1's status to _Psyscall. 3. G1/M1's reentersyscall observes gcwaiting != 0 and calls entersyscall_gcwait. 4. G1/M1's entersyscall_gcwait blocks acquiring sched.lock. Back on GC: 5. stopTheWorld cas's P1's status to _Pgcstop, does other stuff, and returns. 6. GC does stuff and then calls startTheWorld(). 7. startTheWorld() calls procresize(), which sets P1's status to _Pidle and puts P1 on the idle list. Now G2/M2 returns from its syscall and takes over P1: 8. G2/M2 returns from its blocked syscall and gets P1 from the idle list. 9. G2/M2 acquires P1, which sets P1's status to _Prunning. 10. G2/M2 starts a new syscall and invokes reentersyscall, which sets P1's status to _Psyscall. Back on G1/M1: 11. G1/M1 finally acquires sched.lock in entersyscall_gcwait. At this point, G1/M1 still thinks it's running on P1. P1's status is _Psyscall, which is consistent with what G1/M1 is doing, but it's _Psyscall because *G2/M2* put it in to _Psyscall, not G1/M1. This is basically an ABA race on P1's status. Because forEachP currently shares stopwait with stopTheWorld. G1/M1's entersyscall_gcwait observes the non-zero stopwait set by forEachP, but mistakes it for a stopTheWorld. It cas's P1's status from _Psyscall (set by G2/M2) to _Pgcstop and proceeds to decrement stopwait one more time than forEachP was expecting. Fixes #10618. (See the issue for details on why the above race is safe when forEachP is not involved.) Prior to this commit, the command stress ./runtime.test -test.run TestFutexsleep\|TestGoroutineProfile would reliably fail after a few hundred runs. With this commit, it ran for over 2 million runs and never crashed. Change-Id: I9a91ea20035b34b6e5f07ef135b144115f281f30 Reviewed-on: https://go-review.googlesource.com/10157Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently, startTheWorld releases worldsema before starting the world. Since startTheWorld can change gomaxprocs after allowing Ps to run, this means that gomaxprocs can change while another P holds worldsema. Unfortunately, the garbage collector and forEachP assume that holding worldsema protects against changes in gomaxprocs (which it *almost* does). In particular, this is causing somewhat frequent "P did not run fn" crashes in forEachP in the runtime tests because gomaxprocs is changing between the several loops that forEachP does over all the Ps. Fix this by only releasing worldsema after the world is started. This relates to issue #10618. forEachP still fails under stress testing, but much less frequently. Change-Id: I085d627b70cca9ebe9af28fe73b9872f1bb224ff Reviewed-on: https://go-review.googlesource.com/10156Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently, startTheWorld clears preemptoff for the current M before starting the world. A few callers increment m.locks around startTheWorld, presumably to prevent preemption any time during starting the world. This is almost certainly pointless (none of the other callers do this), but there's no harm in making startTheWorld keep preemption disabled until it's all done, which definitely lets us drop these m.locks manipulations. Change-Id: I8a93658abd0c72276c9bafa3d2c7848a65b4691a Reviewed-on: https://go-review.googlesource.com/10155Reviewed-by: Russ Cox <rsc@golang.org>
-