1. 04 May, 2015 3 commits
  2. 03 May, 2015 6 commits
  3. 02 May, 2015 5 commits
  4. 01 May, 2015 21 commits
    • Dave Cheney's avatar
      cmd/internal/obj: remove Biobuf unget · 8d16253c
      Dave Cheney authored
      This change applies CL 9365 to the copy of Biobuf in cmd/internal/obj.
      
      In the process I discovered that some of the methods that should have been
      checking the unget buffer before reading were not and it was probably just
      dumb luck that we handn't hit these issues before; Bungetc is only used in
      one place in cmd/internal/gc and only an unlikely code path.
      
      Change-Id: Ifa0c5c08442e9fe951a5078c6e9ec77a8a4dc2ff
      Reviewed-on: https://go-review.googlesource.com/9529Reviewed-by: default avatarDaniel Morsing <daniel.morsing@gmail.com>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default avatarDave Cheney <dave@cheney.net>
      Run-TryBot: Dave Cheney <dave@cheney.net>
      8d16253c
    • Brad Fitzpatrick's avatar
      net/http: fix scheduling race resulting in flaky test · c723230e
      Brad Fitzpatrick authored
      The test was measuring something, assuming other goroutines had
      already scheduled.
      
      Fixes #10427
      
      Change-Id: I2a4d3906f9d4b5ea44b57d972e303bbe2b0b1cde
      Reviewed-on: https://go-review.googlesource.com/9561Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      c723230e
    • Didier Spezia's avatar
      text/template: detect unmatched else at parsing time · 80cedf3e
      Didier Spezia authored
      An unmatched {{else}} should trigger a parsing error.
      
      The top level parser is able to issue an error in case
      of unmatched {{end}}. It does it a posteriori (i.e. after having
      parsed the action).
      
      Extend this behavior to also check for unmatched {{else}}
      
      Fixes #10611
      
      Change-Id: I1d4f433cc64e11bea5f4d61419ccc707ac01bb1d
      Reviewed-on: https://go-review.googlesource.com/9620Reviewed-by: default avatarRob Pike <r@golang.org>
      80cedf3e
    • Didier Spezia's avatar
      cmd/internal/gc,ld: use new flag argument syntax · 8a072ada
      Didier Spezia authored
      The usage messages for the flags in gc and ld are using the old
      flag argument syntax:
         "arg: description using arg"
      
      Update them to the Go 1.5 flag package's syntax:
         "description using arg"
      
      Fixes #10505
      
      Change-Id: Ifa54ff91e1fd644cfc9a3b41e10176eac3654137
      Reviewed-on: https://go-review.googlesource.com/9505Reviewed-by: default avatarRob Pike <r@golang.org>
      8a072ada
    • Austin Clements's avatar
      runtime: detailed debug output of controller state · dc870d5f
      Austin Clements authored
      This adds a detailed debug dump of the state of the GC controller and
      a GODEBUG flag to enable it.
      
      Change-Id: I562fed7981691a84ddf0f9e6fcd9f089f497ac13
      Reviewed-on: https://go-review.googlesource.com/9640Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      dc870d5f
    • Russ Cox's avatar
      runtime: correct accounting of scan work and bytes marked · 4fffc50c
      Russ Cox authored
      (1) Count pointer-free objects found during scanning roots
      as marked bytes, by not zeroing the mark total after scanning roots.
      
      (2) Don't count the bytes for the roots themselves, by not adding
      them to the mark total in scanblock (the zeroing removed by (1)
      was aimed at that add but hitting more).
      
      Combined, (1) and (2) fix the calculation of the marked heap size.
      This makes the GC trigger much less often in the Go 1 benchmarks,
      which have a global []byte pointing at 256 MB of data.
      That 256 MB allocation was not being included in the heap size
      in the current code, but was included in Go 1.4.
      This is the source of much of the relative slowdown in that directory.
      
      (3) Count the bytes for the roots as scanned work, by not zeroing
      the scan total after scanning roots. There is no strict justification
      for this, and it probably doesn't matter much either way,
      but it was always combined with another buggy zeroing
      (removed in (1)), so guilty by association.
      
      Austin noticed this.
      
      name                                    old mean                new mean        delta
      BenchmarkBinaryTree17              13.1s × (0.97,1.03)      5.9s × (0.97,1.05)  -55.19% (p=0.000)
      BenchmarkFannkuch11                4.35s × (0.99,1.01)     4.37s × (1.00,1.01)  +0.47% (p=0.032)
      BenchmarkFmtFprintfEmpty          84.6ns × (0.95,1.14)    85.7ns × (0.94,1.05)  ~ (p=0.521)
      BenchmarkFmtFprintfString          320ns × (0.95,1.06)     283ns × (0.99,1.02)  -11.48% (p=0.000)
      BenchmarkFmtFprintfInt             311ns × (0.98,1.03)     288ns × (0.99,1.02)  -7.26% (p=0.000)
      BenchmarkFmtFprintfIntInt          554ns × (0.96,1.05)     478ns × (0.99,1.02)  -13.70% (p=0.000)
      BenchmarkFmtFprintfPrefixedInt     434ns × (0.96,1.06)     393ns × (0.98,1.04)  -9.60% (p=0.000)
      BenchmarkFmtFprintfFloat           620ns × (0.99,1.03)     584ns × (0.99,1.01)  -5.73% (p=0.000)
      BenchmarkFmtManyArgs              2.19µs × (0.98,1.03)    1.94µs × (0.99,1.01)  -11.62% (p=0.000)
      BenchmarkGobDecode                21.2ms × (0.97,1.06)    15.2ms × (0.99,1.01)  -28.17% (p=0.000)
      BenchmarkGobEncode                18.1ms × (0.94,1.06)    11.8ms × (0.99,1.01)  -35.00% (p=0.000)
      BenchmarkGzip                      650ms × (0.98,1.01)     649ms × (0.99,1.02)  ~ (p=0.802)
      BenchmarkGunzip                    143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.438)
      BenchmarkHTTPClientServer          110µs × (0.98,1.04)     101µs × (0.98,1.02)  -8.79% (p=0.000)
      BenchmarkJSONEncode               40.3ms × (0.97,1.03)    31.8ms × (0.98,1.03)  -20.92% (p=0.000)
      BenchmarkJSONDecode                119ms × (0.97,1.02)     108ms × (0.99,1.02)  -9.15% (p=0.000)
      BenchmarkMandelbrot200            6.03ms × (1.00,1.01)    6.03ms × (0.99,1.01)  ~ (p=0.750)
      BenchmarkGoParse                  8.58ms × (0.89,1.10)    6.80ms × (1.00,1.00)  -20.71% (p=0.000)
      BenchmarkRegexpMatchEasy0_32       162ns × (1.00,1.01)     162ns × (0.99,1.02)  ~ (p=0.131)
      BenchmarkRegexpMatchEasy0_1K       540ns × (0.99,1.02)     559ns × (0.99,1.02)  +3.58% (p=0.000)
      BenchmarkRegexpMatchEasy1_32       139ns × (0.98,1.04)     139ns × (1.00,1.00)  ~ (p=0.466)
      BenchmarkRegexpMatchEasy1_1K       889ns × (0.99,1.01)     885ns × (0.99,1.01)  -0.50% (p=0.022)
      BenchmarkRegexpMatchMedium_32      252ns × (0.99,1.02)     252ns × (0.99,1.01)  ~ (p=0.469)
      BenchmarkRegexpMatchMedium_1K     72.9µs × (0.99,1.01)    73.6µs × (0.99,1.03)  ~ (p=0.168)
      BenchmarkRegexpMatchHard_32       3.87µs × (1.00,1.01)    3.86µs × (1.00,1.00)  ~ (p=0.055)
      BenchmarkRegexpMatchHard_1K        118µs × (0.99,1.01)     117µs × (0.99,1.00)  ~ (p=0.133)
      BenchmarkRevcomp                   995ms × (0.94,1.10)     949ms × (0.99,1.01)  -4.64% (p=0.000)
      BenchmarkTemplate                  141ms × (0.97,1.02)     127ms × (0.99,1.01)  -10.00% (p=0.000)
      BenchmarkTimeParse                 641ns × (0.99,1.01)     623ns × (0.99,1.01)  -2.79% (p=0.000)
      BenchmarkTimeFormat                729ns × (0.98,1.03)     679ns × (0.99,1.00)  -6.93% (p=0.000)
      
      Change-Id: I839bd7356630d18377989a0748763414e15ed057
      Reviewed-on: https://go-review.googlesource.com/9602Reviewed-by: default avatarAustin Clements <austin@google.com>
      4fffc50c
    • Russ Cox's avatar
      cmd/internal/gc, runtime: use 1-bit bitmap for stack frames, data, bss · 4d0f3a1c
      Russ Cox authored
      The bitmaps were 2 bits per pointer because we needed to distinguish
      scalar, pointer, multiword, and we used the leftover value to distinguish
      uninitialized from scalar, even though the garbage collector (GC) didn't care.
      
      Now that there are no multiword structures from the GC's point of view,
      cut the bitmaps down to 1 bit per pointer, recording just live pointer vs not.
      
      The GC assumes the same layout for stack frames and for the maps
      describing the global data and bss sections, so change them all in one CL.
      
      The code still refers to 4-bit heap bitmaps and 2-bit "type bitmaps", since
      the 2-bit representation lives (at least for now) in some of the reflect data.
      
      Because these stack frame bitmaps are stored directly in the rodata in
      the binary, this CL reduces the size of the 6g binary by about 1.1%.
      
      Performance change is basically a wash, but using less memory,
      and smaller binaries, and enables other bitmap reductions.
      
      name                                      old mean                new mean        delta
      BenchmarkBinaryTree17                13.2s × (0.97,1.03)     13.0s × (0.99,1.01)  -0.93% (p=0.005)
      BenchmarkBinaryTree17-2              9.69s × (0.96,1.05)     9.51s × (0.96,1.03)  -1.86% (p=0.001)
      BenchmarkBinaryTree17-4              10.1s × (0.97,1.05)     10.0s × (0.96,1.05)  ~ (p=0.141)
      BenchmarkFannkuch11                  4.35s × (0.99,1.01)     4.43s × (0.98,1.04)  +1.75% (p=0.001)
      BenchmarkFannkuch11-2                4.31s × (0.99,1.03)     4.32s × (1.00,1.00)  ~ (p=0.095)
      BenchmarkFannkuch11-4                4.32s × (0.99,1.02)     4.38s × (0.98,1.04)  +1.38% (p=0.008)
      BenchmarkFmtFprintfEmpty            83.5ns × (0.97,1.10)    87.3ns × (0.92,1.11)  +4.55% (p=0.014)
      BenchmarkFmtFprintfEmpty-2          81.8ns × (0.98,1.04)    82.5ns × (0.97,1.08)  ~ (p=0.364)
      BenchmarkFmtFprintfEmpty-4          80.9ns × (0.99,1.01)    82.6ns × (0.97,1.08)  +2.12% (p=0.010)
      BenchmarkFmtFprintfString            320ns × (0.95,1.04)     322ns × (0.97,1.05)  ~ (p=0.368)
      BenchmarkFmtFprintfString-2          303ns × (0.97,1.04)     304ns × (0.97,1.04)  ~ (p=0.484)
      BenchmarkFmtFprintfString-4          305ns × (0.97,1.05)     306ns × (0.98,1.05)  ~ (p=0.543)
      BenchmarkFmtFprintfInt               311ns × (0.98,1.03)     319ns × (0.97,1.03)  +2.63% (p=0.000)
      BenchmarkFmtFprintfInt-2             297ns × (0.98,1.04)     301ns × (0.97,1.04)  +1.19% (p=0.023)
      BenchmarkFmtFprintfInt-4             302ns × (0.98,1.02)     304ns × (0.97,1.03)  ~ (p=0.126)
      BenchmarkFmtFprintfIntInt            554ns × (0.96,1.05)     554ns × (0.97,1.03)  ~ (p=0.975)
      BenchmarkFmtFprintfIntInt-2          520ns × (0.98,1.03)     517ns × (0.98,1.02)  ~ (p=0.153)
      BenchmarkFmtFprintfIntInt-4          524ns × (0.98,1.02)     525ns × (0.98,1.03)  ~ (p=0.597)
      BenchmarkFmtFprintfPrefixedInt       433ns × (0.97,1.06)     434ns × (0.97,1.06)  ~ (p=0.804)
      BenchmarkFmtFprintfPrefixedInt-2     413ns × (0.98,1.04)     413ns × (0.98,1.03)  ~ (p=0.881)
      BenchmarkFmtFprintfPrefixedInt-4     420ns × (0.97,1.03)     421ns × (0.97,1.03)  ~ (p=0.561)
      BenchmarkFmtFprintfFloat             620ns × (0.99,1.03)     636ns × (0.97,1.03)  +2.57% (p=0.000)
      BenchmarkFmtFprintfFloat-2           601ns × (0.98,1.02)     617ns × (0.98,1.03)  +2.58% (p=0.000)
      BenchmarkFmtFprintfFloat-4           613ns × (0.98,1.03)     626ns × (0.98,1.02)  +2.15% (p=0.000)
      BenchmarkFmtManyArgs                2.19µs × (0.96,1.04)    2.23µs × (0.97,1.02)  +1.65% (p=0.000)
      BenchmarkFmtManyArgs-2              2.08µs × (0.98,1.03)    2.10µs × (0.99,1.02)  +0.79% (p=0.019)
      BenchmarkFmtManyArgs-4              2.10µs × (0.98,1.02)    2.13µs × (0.98,1.02)  +1.72% (p=0.000)
      BenchmarkGobDecode                  21.3ms × (0.97,1.05)    21.1ms × (0.97,1.04)  -1.36% (p=0.025)
      BenchmarkGobDecode-2                20.0ms × (0.97,1.03)    19.2ms × (0.97,1.03)  -4.00% (p=0.000)
      BenchmarkGobDecode-4                19.5ms × (0.99,1.02)    19.0ms × (0.99,1.01)  -2.39% (p=0.000)
      BenchmarkGobEncode                  18.3ms × (0.95,1.07)    18.1ms × (0.96,1.08)  ~ (p=0.305)
      BenchmarkGobEncode-2                16.8ms × (0.97,1.02)    16.4ms × (0.98,1.02)  -2.79% (p=0.000)
      BenchmarkGobEncode-4                15.4ms × (0.98,1.02)    15.4ms × (0.98,1.02)  ~ (p=0.465)
      BenchmarkGzip                        650ms × (0.98,1.03)     655ms × (0.97,1.04)  ~ (p=0.075)
      BenchmarkGzip-2                      652ms × (0.98,1.03)     655ms × (0.98,1.02)  ~ (p=0.337)
      BenchmarkGzip-4                      656ms × (0.98,1.04)     653ms × (0.98,1.03)  ~ (p=0.291)
      BenchmarkGunzip                      143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.507)
      BenchmarkGunzip-2                    143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.313)
      BenchmarkGunzip-4                    143ms × (1.00,1.01)     143ms × (1.00,1.01)  ~ (p=0.312)
      BenchmarkHTTPClientServer            110µs × (0.98,1.03)     109µs × (0.99,1.02)  -1.40% (p=0.000)
      BenchmarkHTTPClientServer-2          154µs × (0.90,1.08)     149µs × (0.90,1.08)  -3.43% (p=0.007)
      BenchmarkHTTPClientServer-4          138µs × (0.97,1.04)     138µs × (0.96,1.04)  ~ (p=0.670)
      BenchmarkJSONEncode                 40.2ms × (0.98,1.02)    40.2ms × (0.98,1.05)  ~ (p=0.828)
      BenchmarkJSONEncode-2               35.1ms × (0.99,1.02)    35.2ms × (0.98,1.03)  ~ (p=0.392)
      BenchmarkJSONEncode-4               35.3ms × (0.98,1.03)    35.3ms × (0.98,1.02)  ~ (p=0.813)
      BenchmarkJSONDecode                  119ms × (0.97,1.02)     117ms × (0.98,1.02)  -1.80% (p=0.000)
      BenchmarkJSONDecode-2                115ms × (0.99,1.02)     114ms × (0.98,1.02)  -1.18% (p=0.000)
      BenchmarkJSONDecode-4                116ms × (0.98,1.02)     114ms × (0.98,1.02)  -1.43% (p=0.000)
      BenchmarkMandelbrot200              6.03ms × (1.00,1.01)    6.03ms × (1.00,1.01)  ~ (p=0.985)
      BenchmarkMandelbrot200-2            6.03ms × (1.00,1.01)    6.02ms × (1.00,1.01)  ~ (p=0.320)
      BenchmarkMandelbrot200-4            6.03ms × (1.00,1.01)    6.03ms × (1.00,1.01)  ~ (p=0.799)
      BenchmarkGoParse                    8.63ms × (0.89,1.10)    8.58ms × (0.93,1.09)  ~ (p=0.667)
      BenchmarkGoParse-2                  8.20ms × (0.97,1.04)    8.37ms × (0.97,1.04)  +1.96% (p=0.001)
      BenchmarkGoParse-4                  8.00ms × (0.98,1.02)    8.14ms × (0.99,1.02)  +1.75% (p=0.000)
      BenchmarkRegexpMatchEasy0_32         162ns × (1.00,1.01)     164ns × (0.98,1.04)  +1.35% (p=0.011)
      BenchmarkRegexpMatchEasy0_32-2       161ns × (1.00,1.01)     161ns × (1.00,1.00)  ~ (p=0.185)
      BenchmarkRegexpMatchEasy0_32-4       161ns × (1.00,1.00)     161ns × (1.00,1.00)  -0.19% (p=0.001)
      BenchmarkRegexpMatchEasy0_1K         540ns × (0.99,1.02)     566ns × (0.98,1.04)  +4.98% (p=0.000)
      BenchmarkRegexpMatchEasy0_1K-2       540ns × (0.99,1.01)     557ns × (0.99,1.01)  +3.21% (p=0.000)
      BenchmarkRegexpMatchEasy0_1K-4       541ns × (0.99,1.01)     559ns × (0.99,1.01)  +3.26% (p=0.000)
      BenchmarkRegexpMatchEasy1_32         139ns × (0.98,1.04)     139ns × (0.99,1.03)  ~ (p=0.979)
      BenchmarkRegexpMatchEasy1_32-2       139ns × (0.99,1.04)     139ns × (0.99,1.02)  ~ (p=0.777)
      BenchmarkRegexpMatchEasy1_32-4       139ns × (0.98,1.04)     139ns × (0.99,1.04)  ~ (p=0.771)
      BenchmarkRegexpMatchEasy1_1K         890ns × (0.99,1.03)     885ns × (1.00,1.01)  -0.50% (p=0.004)
      BenchmarkRegexpMatchEasy1_1K-2       888ns × (0.99,1.01)     885ns × (0.99,1.01)  -0.37% (p=0.004)
      BenchmarkRegexpMatchEasy1_1K-4       890ns × (0.99,1.02)     884ns × (1.00,1.00)  -0.70% (p=0.000)
      BenchmarkRegexpMatchMedium_32        252ns × (0.99,1.01)     251ns × (0.99,1.01)  ~ (p=0.081)
      BenchmarkRegexpMatchMedium_32-2      254ns × (0.99,1.04)     252ns × (0.99,1.01)  -0.78% (p=0.027)
      BenchmarkRegexpMatchMedium_32-4      253ns × (0.99,1.04)     252ns × (0.99,1.01)  -0.70% (p=0.022)
      BenchmarkRegexpMatchMedium_1K       72.9µs × (0.99,1.01)    72.7µs × (1.00,1.00)  ~ (p=0.064)
      BenchmarkRegexpMatchMedium_1K-2     74.1µs × (0.98,1.05)    72.9µs × (1.00,1.01)  -1.61% (p=0.001)
      BenchmarkRegexpMatchMedium_1K-4     73.6µs × (0.99,1.05)    72.8µs × (1.00,1.00)  -1.13% (p=0.007)
      BenchmarkRegexpMatchHard_32         3.88µs × (0.99,1.03)    3.92µs × (0.98,1.05)  ~ (p=0.143)
      BenchmarkRegexpMatchHard_32-2       3.89µs × (0.99,1.03)    3.93µs × (0.98,1.09)  ~ (p=0.278)
      BenchmarkRegexpMatchHard_32-4       3.90µs × (0.99,1.05)    3.93µs × (0.98,1.05)  ~ (p=0.252)
      BenchmarkRegexpMatchHard_1K          118µs × (0.99,1.01)     117µs × (0.99,1.02)  -0.54% (p=0.003)
      BenchmarkRegexpMatchHard_1K-2        118µs × (0.99,1.01)     118µs × (0.99,1.03)  ~ (p=0.581)
      BenchmarkRegexpMatchHard_1K-4        118µs × (0.99,1.02)     117µs × (0.99,1.01)  -0.54% (p=0.002)
      BenchmarkRevcomp                     991ms × (0.95,1.10)     989ms × (0.94,1.08)  ~ (p=0.879)
      BenchmarkRevcomp-2                   978ms × (0.95,1.11)     962ms × (0.96,1.08)  ~ (p=0.257)
      BenchmarkRevcomp-4                   979ms × (0.96,1.07)     974ms × (0.96,1.11)  ~ (p=0.678)
      BenchmarkTemplate                    141ms × (0.99,1.02)     145ms × (0.99,1.02)  +2.75% (p=0.000)
      BenchmarkTemplate-2                  135ms × (0.98,1.02)     138ms × (0.99,1.02)  +2.34% (p=0.000)
      BenchmarkTemplate-4                  136ms × (0.98,1.02)     140ms × (0.99,1.02)  +2.71% (p=0.000)
      BenchmarkTimeParse                   640ns × (0.99,1.01)     622ns × (0.99,1.01)  -2.88% (p=0.000)
      BenchmarkTimeParse-2                 640ns × (0.99,1.01)     622ns × (1.00,1.00)  -2.81% (p=0.000)
      BenchmarkTimeParse-4                 640ns × (1.00,1.01)     622ns × (0.99,1.01)  -2.82% (p=0.000)
      BenchmarkTimeFormat                  730ns × (0.98,1.02)     731ns × (0.98,1.03)  ~ (p=0.767)
      BenchmarkTimeFormat-2                709ns × (0.99,1.02)     707ns × (0.99,1.02)  ~ (p=0.347)
      BenchmarkTimeFormat-4                717ns × (0.98,1.01)     718ns × (0.98,1.02)  ~ (p=0.793)
      
      Change-Id: Ie779c47e912bf80eb918bafa13638bd8dfd6c2d9
      Reviewed-on: https://go-review.googlesource.com/9406Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      4d0f3a1c
    • Dave Cheney's avatar
      cmd/internal/obj: clean up Biobuf · e9ab343f
      Dave Cheney authored
      This is a follow up to rev 443a32e7 which reduces some of the
      duplication between methods and functions that operate on obj.Biobuf.
      
      obj.Biobuf has Flush and Write methods as well as helpers which duplicate
      those methods, consolidate on the former and remove the latter.
      
      Also, address a final comment from CL 9525.
      
      Change-Id: I67deaf3a163bb489a9bb21bb39524785d7a2f6c5
      Reviewed-on: https://go-review.googlesource.com/9527Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      e9ab343f
    • David Chase's avatar
      cmd/internal/gc: Toughen escape analysis against some bugs. · bc44b818
      David Chase authored
      Ensures that parameter flow bits are not set for tags EscScope, EscHeap, EscNever;
      crash the compiler earl to expose faulty logic, rather than flake out silently downstream.
      
      Change-Id: I1428129980ae047d02975f033d56cbbd04f49579
      Reviewed-on: https://go-review.googlesource.com/9601Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      bc44b818
    • Josh Bleecher Snyder's avatar
      Revert "runtime/pprof: write heap statistics to heap profile always" · 7bebccb9
      Josh Bleecher Snyder authored
      This reverts commit c26fc88d.
      
      This broke pprof. See the comments at 9491.
      
      Change-Id: Ic99ce026e86040c050a9bf0ea3024a1a42274ad1
      Reviewed-on: https://go-review.googlesource.com/9565Reviewed-by: default avatarDaniel Morsing <daniel.morsing@gmail.com>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      7bebccb9
    • Keith Randall's avatar
      cmd/dist, runtime: Make stack guard larger for non-optimized builds · a55b1313
      Keith Randall authored
      Kind of a hack, but makes the non-optimized builds pass.
      
      Fixes #10079
      
      Change-Id: I26f41c546867f8f3f16d953dc043e784768f2aff
      Reviewed-on: https://go-review.googlesource.com/9552Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      a55b1313
    • David Chase's avatar
      cmd/internal/gc: improve flow of input params to output params · 7fbb1b36
      David Chase authored
      This includes the following information in the per-function summary:
      
      outK = paramJ   encoded in outK bits for paramJ
      outK = *paramJ  encoded in outK bits for paramJ
      heap = paramJ   EscHeap
      heap = *paramJ  EscContentEscapes
      
      Note that (currently) if the address of a parameter is taken and
      returned, necessarily a heap allocation occurred to contain that
      reference, and the heap can never refer to stack, therefore the
      parameter and everything downstream from it escapes to the heap.
      
      The per-function summary information now has a tuneable number of bits
      (2 is probably noticeably better than 1, 3 is likely overkill, but it
      is now easy to check and the -m debugging output includes information
      that allows you to figure out if more would be better.)
      
      A new test was  added to check pointer flow through struct-typed and
      *struct-typed parameters and returns; some of these are sensitive to
      the number of summary bits, and ought to yield better results with a
      more competent escape analysis algorithm.  Another new test checks
      (some) correctness with array parameters, results, and operations.
      
      The old analysis inferred a piece of plan9 runtime was non-escaping by
      counteracting overconservative analysis with buggy analysis; with the
      bug fixed, the result was too conservative (and it's not easy to fix
      in this framework) so the source code was tweaked to get the desired
      result.  A test was added against the discovered bug.
      
      The escape analysis was further improved splitting the "level" into
      3 parts, one tracking the conventional "level" and the other two
      computing the highest-level-suffix-from-copy, which is used to
      generally model the cancelling effect of indirection applied to
      address-of.
      
      With the improved escape analysis enabled, it was necessary to
      modify one of the runtime tests because it now attempts to allocate
      too much on the (small, fixed-size) G0 (system) stack and this
      failed the test.
      
      Compiling src/std after touching src/runtime/*.go with -m logging
      turned on shows 420 fewer heap allocation sites (10538 vs 10968).
      
      Profiling allocations in src/html/template with
      for i in {1..5} ;
        do go tool 6g -memprofile=mastx.${i}.prof  -memprofilerate=1 *.go;
        go tool pprof -alloc_objects -text  mastx.${i}.prof ;
      done
      
      showed a 15% reduction in allocations performed by the compiler.
      
      Update #3753
      Update #4720
      Fixes #10466
      
      Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
      Reviewed-on: https://go-review.googlesource.com/8202
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      7fbb1b36
    • David Crawshaw's avatar
      runtime/cgo, cmd/dist: turn off exc_bad_access handler by default · 4044aded
      David Crawshaw authored
      App Store policy requires programs do not reference the exc_server
      symbol. (Some public forum threads show that Unity ran into this
      several years ago and it is a hard policy rule.) While some research
      suggests that I could write my own version of exc_server, the
      expedient course is to disable the exception handler by default.
      
      Go programs only need it when running under lldb, which is primarily
      used by tests. So enable the exception handler in cmd/dist when we
      are running the tests.
      
      Fixes #10646
      
      Change-Id: I853905254894b5367edb8abd381d45585a78ee8b
      Reviewed-on: https://go-review.googlesource.com/9549Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      4044aded
    • Shenghou Ma's avatar
      runtime: adjust traceTickDiv for non-x86 architectures · 5f69e739
      Shenghou Ma authored
      Fixes #10554.
      Fixes #10623.
      
      Change-Id: I90fbaa34e3d55c8758178f8d2e7fa41ff1194a1b
      Signed-off-by: default avatarShenghou Ma <minux@golang.org>
      Reviewed-on: https://go-review.googlesource.com/9247Reviewed-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: default avatarDave Cheney <dave@cheney.net>
      5f69e739
    • Dave Cheney's avatar
      cmd/cover: fix build · ffd33449
      Dave Cheney authored
      Fix the various builds which don't have a real filesystem or don't support forking.
      
      Change-Id: I3075c662fe6191ecbe70ba359b73d9a88bb06f35
      Reviewed-on: https://go-review.googlesource.com/9528Reviewed-by: default avatarRob Pike <r@golang.org>
      Reviewed-by: default avatarDave Cheney <dave@cheney.net>
      ffd33449
    • Rob Pike's avatar
      cmd/cover: try once again to fix the build · bc1410a4
      Rob Pike authored
      Forgot to update the references to the old cover package. No excuse.
      
      Change-Id: If17b7521f0bf70bc0c8da9c5adf246d90f644637
      Reviewed-on: https://go-review.googlesource.com/9564Reviewed-by: default avatarRob Pike <r@golang.org>
      bc1410a4
    • Rob Pike's avatar
      cmd/cover: fix build · e0820ac8
      Rob Pike authored
      TBR=rsc
      
      Change-Id: I6ec69013027213c5e7adedd2edb89dea6af876d9
      Reviewed-on: https://go-review.googlesource.com/9563Reviewed-by: default avatarRob Pike <r@golang.org>
      e0820ac8
    • Dave Cheney's avatar
      cmd/8g: don't call gc.Fatal during initalisation · 443a32e7
      Dave Cheney authored
      Fixes #10592
      
      Calling gc.Fatal before gc.Main has been called ends up flushing gc.bstdout before
      it is properly set up. Ideally obj.Bflush would handle this case, but that type
      and its callers are rather convoluted, so take the simpler route and avoid calling
      gc.Fatal altogether.
      
      Change-Id: I338b469e86edba558b6bedff35bb904bfc3d6990
      Reviewed-on: https://go-review.googlesource.com/9525Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarDave Cheney <dave@cheney.net>
      Run-TryBot: Dave Cheney <dave@cheney.net>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      443a32e7
    • Rob Pike's avatar
      text/template: allow newlines in raw quotes · 04220014
      Rob Pike authored
      This was disallowed for error-checking reasons but people ask for
      it, it's easy, and it's clear what it all means.
      
      Fixes #7323.
      
      Change-Id: I26542f5ac6519e45b335ad789713a4d9e356279b
      Reviewed-on: https://go-review.googlesource.com/9537Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      04220014
    • Rob Pike's avatar
      doc/go1.5.txt: cover has moved · cf3ac26a
      Rob Pike authored
      Change-Id: Ie4b59d72e2b704559e075494e79fdc7b0bca6556
      Reviewed-on: https://go-review.googlesource.com/9562Reviewed-by: default avatarRob Pike <r@golang.org>
      cf3ac26a
    • Rob Pike's avatar
      cmd/cover: copy to standard repository from golang.org/x/tools/cmd/cover · 5eddc5ba
      Rob Pike authored
      This required dealing with the ill-advised split of the profile code
      into a separate package. I just copied it over unchanged. The package
      does not deserve to be in the standard repository. We can cope
      with the duplication.
      
      Also update the go command to know about the new location.
      
      Fixes #10528.
      
      Change-Id: I05170ef3663326d57b9c18888d01163acd9256b6
      Reviewed-on: https://go-review.googlesource.com/9560Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      5eddc5ba
  5. 30 Apr, 2015 5 commits