- 21 May, 2015 7 commits
-
-
Russ Cox authored
This CL removes the remaining visible uses of the "architecture letter" concept. (They are no longer in tool names nor in source directory names.) Because the architecture letter concept is now gone, delete GOCHAR from "go env" output, and change go/build.ArchChar to return an error always. The architecture letter is still used in the compiler and linker sources as a clumsy architecture enumeration, but that use is not visible to Go users and can be cleaned up separately. Change-Id: I4d97a38f372003fb610c9c5241bea440d9dbeb8d Reviewed-on: https://go-review.googlesource.com/10289Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
This CL fixes the build to use the newly created go tool compile and go tool link in place of go tool 5g, go tool 5l, and so on. See golang-dev thread titled "go tool compile, etc" for background. Although it was not a primary motivation, this conversion does reduce the wall clock time and cpu time required for make.bash by about 10%. Change-Id: I79cbbdb676cab029db8aeefb99a53178ff55f98d Reviewed-on: https://go-review.googlesource.com/10288Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Trivial merging of 5g, 6g, ... into go tool compile, and similarlly 5l, 6l, ... into go tool link. The files compile/main.go and link/main.go are new. Everything else in those directories is a move followed by change of imports and package name. This CL breaks the build. Manual fixups are in the next CL. See golang-dev thread titled "go tool compile, etc" for background. Change-Id: Id35ff5a5859ad9037c61275d637b1bd51df6828b Reviewed-on: https://go-review.googlesource.com/10287Reviewed-by: Dave Cheney <dave@cheney.net> Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
In preparation for making the current linker cmd/link. If cmd/newlink is ever completed, it can be moved back. See golang-dev thread titled "go tool compile, etc" for background. Change-Id: I4029580f470038240c5181a37ea4202ba971f9ef Reviewed-on: https://go-review.googlesource.com/10286Reviewed-by: Rob Pike <r@golang.org>
-
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 9 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>
-