1. 22 Nov, 2016 4 commits
  2. 21 Nov, 2016 8 commits
  3. 20 Nov, 2016 2 commits
    • Austin Clements's avatar
      runtime: wake idle Ps when enqueuing GC work · 0bae74e8
      Austin Clements authored
      If the scheduler has no user work and there's no GC work visible, it
      puts the P to sleep (or blocks on the network). However, if we later
      enqueue more GC work, there's currently nothing that specifically
      wakes up the scheduler to let it start an idle GC worker. As a result,
      we can underutilize the CPU during GC if Ps have been put to sleep.
      
      Fix this by making GC wake idle Ps when work buffers are put on the
      full list. We already have a hook to do this, since we use this to
      preempt a random P if we need more dedicated workers. We expand this
      hook to instead wake an idle P if there is one. The logic we use for
      this is identical to the logic used to wake an idle P when we ready a
      goroutine.
      
      To make this really sound, we also fix the scheduler to re-check the
      idle GC worker condition after releasing its P. This closes a race
      where 1) the scheduler checks for idle work and finds none, 2) new
      work is enqueued but there are no idle Ps so none are woken, and 3)
      the scheduler releases its P.
      
      There is one subtlety here. Currently we call enlistWorker directly
      from putfull, but the gcWork is in an inconsistent state in the places
      that call putfull. This isn't a problem right now because nothing that
      enlistWorker does touches the gcWork, but with the added call to
      wakep, it's possible to get a recursive call into the gcWork
      (specifically, while write barriers are disallowed, this can do an
      allocation, which can dispose a gcWork, which can put a workbuf). To
      handle this, we lift the enlistWorker calls up a layer and delay them
      until the gcWork is in a consistent state.
      
      Fixes #14179.
      
      Change-Id: Ia2467a52e54c9688c3c1752e1fc00f5b37bbfeeb
      Reviewed-on: https://go-review.googlesource.com/32434
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      0bae74e8
    • Austin Clements's avatar
      runtime: exit idle worker if there's higher-priority work · 49ea9207
      Austin Clements authored
      Idle GC workers trigger whenever there's a GC running and the
      scheduler doesn't find any other work. However, they currently run for
      a full scheduler quantum (~10ms) once started.
      
      This is really bad for event-driven applications, where work may come
      in on the network hundreds of times during that window. In the
      go-gcbench rpc benchmark, this is bad enough to often cause effective
      STWs where all Ps are in the idle worker. When this happens, we don't
      even poll the network any more (except for the background 10ms poll in
      sysmon), so we don't even know there's more work to do.
      
      Fix this by making idle workers check with the scheduler roughly every
      100 µs to see if there's any higher-priority work the P should be
      doing. This check includes polling the network for incoming work.
      
      Fixes #16528.
      
      Change-Id: I6f62ebf6d36a92368da9891bafbbfd609b9bd003
      Reviewed-on: https://go-review.googlesource.com/32433
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      49ea9207
  4. 19 Nov, 2016 1 commit
  5. 18 Nov, 2016 11 commits
    • Robert Griesemer's avatar
      go/internal/gccgoimporter: handle conversions in exported const values · f42929ce
      Robert Griesemer authored
      Also: handle version "v2" of export data format.
      
      Fixes #17981.
      
      Change-Id: I8042ce18c4a27c70cc1ede675daca019b047bcf3
      Reviewed-on: https://go-review.googlesource.com/33412Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      f42929ce
    • Keith Randall's avatar
      cmd/cover: handle multiple samples from the same location · f39050c8
      Keith Randall authored
      So we can merge cover profiles from multiple runs.
      
      Change-Id: I1bf921e2b02063a2a62b35d21a6823062d10e5d0
      Reviewed-on: https://go-review.googlesource.com/23831Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Reviewed-by: 's avatarRob Pike <r@golang.org>
      f39050c8
    • Robert Griesemer's avatar
      spec: add subtitles to section on "for" statements · b01f612a
      Robert Griesemer authored
      This matches what we already do for switch statements and makes
      this large section more visibly organized. No other changes besides
      introducing the titles.
      
      Fixes #4486.
      
      Change-Id: I73f274e4fdd27c6cfeaed79090b4553e57a9c479
      Reviewed-on: https://go-review.googlesource.com/33410Reviewed-by: 's avatarRob Pike <r@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      b01f612a
    • Austin Clements's avatar
      cmd/trace: fix goroutine view · d0b3c169
      Austin Clements authored
      Currently, trace processing interleaves state/statistics updates and
      emitting trace viewer objects. As a result, if events are being
      filtered, either by time or by goroutines, we'll miss those
      state/statistics updates. At best, this leads to bad statistics;
      however, since we're now strictly checking G state transitions, it
      usually leads to a failure to process the trace if there is any
      filtering.
      
      Fix this by separating state updates from emitting trace object. State
      updates are done before filtering, so we always have correct state
      information and statistics. Trace objects are only emitted if we pass
      the filter. To determine when we need to emit trace counters, rather
      than duplicating the knowledge of which events might modify
      statistics, we keep track of the previously emitted counters and emit
      a trace counter object whenever these have changed.
      
      Fixes #17719.
      
      Change-Id: Ic66e3ddaef60d1acaaf2ff4c62baa5352799cf99
      Reviewed-on: https://go-review.googlesource.com/32810Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      d0b3c169
    • Robert Griesemer's avatar
      spec: remove => (alias) operator from Operators and Delimiters section · 0eb26fa8
      Robert Griesemer authored
      (Revert of https://go-review.googlesource.com/#/c/32310/)
      
      For #16339.
      Fixes #17975.
      
      Change-Id: I36062703c423a81ea1c5b00f4429a4faf00b3782
      Reviewed-on: https://go-review.googlesource.com/33365Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      0eb26fa8
    • Robert Griesemer's avatar
      spec: clarify type elision rules for composite literals · 120cf676
      Robert Griesemer authored
      - organize examples better
      - add an example illustrating behavior if element type is a named pointer type
      - both compilers and go/types (per https://go-review.googlesource.com/33358)
        follow this now
      
      See the issue for detailed discussion.
      
      Fixes #17954.
      
      Change-Id: I8d90507ff2347d9493813f75b73233819880d2b4
      Reviewed-on: https://go-review.googlesource.com/33361Reviewed-by: 's avatarRob Pike <r@golang.org>
      120cf676
    • Philip Hofer's avatar
      cmd/compile: in cse, allow for new ssa values · a34fddf4
      Philip Hofer authored
      The table of rewrites in ssa/cse is not sized appropriately for
      ssa IDs that are created during copying of selects into new blocks.
      
      Fixes #17918
      
      Change-Id: I65fe86c6aab5efa679aa473aadc4ee6ea882cd41
      Reviewed-on: https://go-review.googlesource.com/33240Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      a34fddf4
    • Özgür Kesim's avatar
      text/template: handle option missingkey=error consistently · 277bcbbd
      Özgür Kesim authored
      The existing implementation of text/template handles the option
      "missingkey=error" in an inconsitent manner:  If the provided data is
      a nil-interface, no error is returned (despite the fact that no key
      can be found in it).
      
      This patch makes text/template return an error if "missingkey=error"
      is set and the provided data is a not a valid reflect.Value.
      
      Fixes #15356
      
      Change-Id: Ia0a83da48652ecfaf31f18bdbd78cb21dbca1164
      Reviewed-on: https://go-review.googlesource.com/31638Reviewed-by: 's avatarRob Pike <r@golang.org>
      Run-TryBot: Rob Pike <r@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      277bcbbd
    • Cherry Zhang's avatar
      cmd/compile: make a copy of Phi input if it is still live · 348275cd
      Cherry Zhang authored
      Register of Phi input is allocated to the Phi. So if the Phi
      input is still live after Phi, we may need to use a spill. In
      this case, copy the Phi input to a spare register to avoid a
      spill.
      
      Originally targeted the code in issue #16187, and this CL
      indeed removes the spill, but doesn't seem to help on benchmark
      result. It may help in general, though.
      
      On AMD64:
      name                      old time/op    new time/op    delta
      BinaryTree17-12              2.79s ± 1%     2.76s ± 0%  -1.33%  (p=0.000 n=10+10)
      Fannkuch11-12                3.02s ± 0%     3.14s ± 0%  +3.99%  (p=0.000 n=10+10)
      FmtFprintfEmpty-12          51.2ns ± 0%    51.4ns ± 3%    ~      (p=0.368 n=8+10)
      FmtFprintfString-12          145ns ± 0%     144ns ± 0%  -0.69%    (p=0.000 n=6+9)
      FmtFprintfInt-12             127ns ± 1%     124ns ± 1%  -2.79%   (p=0.000 n=10+9)
      FmtFprintfIntInt-12          186ns ± 0%     184ns ± 0%  -1.34%   (p=0.000 n=10+9)
      FmtFprintfPrefixedInt-12     196ns ± 0%     194ns ± 0%  -0.97%    (p=0.000 n=9+9)
      FmtFprintfFloat-12           293ns ± 2%     287ns ± 0%  -2.00%   (p=0.000 n=10+9)
      FmtManyArgs-12               847ns ± 1%     829ns ± 0%  -2.17%   (p=0.000 n=10+7)
      GobDecode-12                7.17ms ± 0%    7.18ms ± 0%    ~     (p=0.123 n=10+10)
      GobEncode-12                6.08ms ± 1%    6.08ms ± 0%    ~      (p=0.497 n=10+9)
      Gzip-12                      277ms ± 1%     275ms ± 1%  -0.47%   (p=0.028 n=10+9)
      Gunzip-12                   39.1ms ± 2%    38.2ms ± 1%  -2.20%   (p=0.000 n=10+9)
      HTTPClientServer-12         90.9µs ± 4%    87.7µs ± 2%  -3.51%   (p=0.001 n=9+10)
      JSONEncode-12               17.3ms ± 1%    16.5ms ± 0%  -5.02%    (p=0.000 n=9+9)
      JSONDecode-12               54.6ms ± 1%    54.1ms ± 0%  -0.99%    (p=0.000 n=9+9)
      Mandelbrot200-12            4.45ms ± 0%    4.45ms ± 0%  -0.02%    (p=0.006 n=8+9)
      GoParse-12                  3.44ms ± 0%    3.48ms ± 1%  +0.95%  (p=0.000 n=10+10)
      RegexpMatchEasy0_32-12      84.9ns ± 0%    85.0ns ± 0%    ~       (p=0.241 n=8+8)
      RegexpMatchEasy0_1K-12       867ns ± 3%     915ns ±11%  +5.55%  (p=0.037 n=10+10)
      RegexpMatchEasy1_32-12      82.7ns ± 5%    83.9ns ± 4%    ~      (p=0.161 n=9+10)
      RegexpMatchEasy1_1K-12       361ns ± 1%     363ns ± 0%    ~      (p=0.098 n=10+8)
      RegexpMatchMedium_32-12      126ns ± 0%     126ns ± 1%    ~      (p=0.549 n=8+10)
      RegexpMatchMedium_1K-12     38.8µs ± 0%    39.1µs ± 0%  +0.67%    (p=0.000 n=9+8)
      RegexpMatchHard_32-12       1.95µs ± 0%    1.96µs ± 0%  +0.43%    (p=0.000 n=9+9)
      RegexpMatchHard_1K-12       59.0µs ± 0%    59.1µs ± 0%  +0.27%   (p=0.000 n=10+9)
      Revcomp-12                   436ms ± 1%     431ms ± 1%  -1.19%  (p=0.005 n=10+10)
      Template-12                 56.7ms ± 1%    57.1ms ± 1%  +0.71%   (p=0.001 n=10+9)
      TimeParse-12                 312ns ± 0%     310ns ± 0%  -0.80%   (p=0.000 n=10+9)
      TimeFormat-12                336ns ± 0%     332ns ± 0%  -1.19%    (p=0.000 n=8+7)
      [Geo mean]                  59.2µs         58.9µs       -0.42%
      
      On PPC64:
      name                     old time/op    new time/op    delta
      BinaryTree17-2              4.67s ± 2%     4.71s ± 1%    ~     (p=0.421 n=5+5)
      Fannkuch11-2                3.92s ± 1%     3.94s ± 0%  +0.46%  (p=0.032 n=5+5)
      FmtFprintfEmpty-2           122ns ± 0%     120ns ± 2%  -1.80%  (p=0.016 n=4+5)
      FmtFprintfString-2          305ns ± 1%     299ns ± 1%  -1.84%  (p=0.008 n=5+5)
      FmtFprintfInt-2             243ns ± 0%     241ns ± 1%  -0.66%  (p=0.016 n=4+5)
      FmtFprintfIntInt-2          361ns ± 1%     356ns ± 1%  -1.49%  (p=0.016 n=5+5)
      FmtFprintfPrefixedInt-2     355ns ± 1%     357ns ± 1%    ~     (p=0.333 n=5+5)
      FmtFprintfFloat-2           502ns ± 2%     498ns ± 1%    ~     (p=0.151 n=5+5)
      FmtManyArgs-2              1.55µs ± 2%    1.59µs ± 1%  +2.52%  (p=0.008 n=5+5)
      GobDecode-2                13.0ms ± 1%    13.0ms ± 1%    ~     (p=0.841 n=5+5)
      GobEncode-2                11.8ms ± 1%    11.8ms ± 1%    ~     (p=0.690 n=5+5)
      Gzip-2                      499ms ± 1%     503ms ± 0%    ~     (p=0.421 n=5+5)
      Gunzip-2                   86.5ms ± 0%    86.4ms ± 1%    ~     (p=0.841 n=5+5)
      HTTPClientServer-2         68.2µs ± 2%    69.6µs ± 3%    ~     (p=0.151 n=5+5)
      JSONEncode-2               39.0ms ± 1%    37.2ms ± 1%  -4.65%  (p=0.008 n=5+5)
      JSONDecode-2                122ms ± 1%     126ms ± 1%  +2.63%  (p=0.008 n=5+5)
      Mandelbrot200-2            6.08ms ± 1%    5.89ms ± 1%  -3.06%  (p=0.008 n=5+5)
      GoParse-2                  5.95ms ± 2%    5.98ms ± 1%    ~     (p=0.421 n=5+5)
      RegexpMatchEasy0_32-2       331ns ± 1%     328ns ± 1%    ~     (p=0.056 n=5+5)
      RegexpMatchEasy0_1K-2      1.45µs ± 0%    1.47µs ± 0%  +1.13%  (p=0.008 n=5+5)
      RegexpMatchEasy1_32-2       359ns ± 0%     353ns ± 0%  -1.84%  (p=0.008 n=5+5)
      RegexpMatchEasy1_1K-2      1.79µs ± 0%    1.81µs ± 1%  +1.16%  (p=0.008 n=5+5)
      RegexpMatchMedium_32-2      420ns ± 2%     413ns ± 0%  -1.72%  (p=0.008 n=5+5)
      RegexpMatchMedium_1K-2     70.2µs ± 1%    69.5µs ± 1%  -1.09%  (p=0.032 n=5+5)
      RegexpMatchHard_32-2       3.87µs ± 1%    3.65µs ± 0%  -5.86%  (p=0.008 n=5+5)
      RegexpMatchHard_1K-2        111µs ± 0%     105µs ± 0%  -5.49%  (p=0.016 n=5+4)
      Revcomp-2                   1.00s ± 1%     1.01s ± 2%    ~     (p=0.151 n=5+5)
      Template-2                  113ms ± 1%     113ms ± 2%    ~     (p=0.841 n=5+5)
      TimeParse-2                 555ns ± 0%     550ns ± 1%  -0.87%  (p=0.032 n=5+5)
      TimeFormat-2                736ns ± 1%     704ns ± 1%  -4.35%  (p=0.008 n=5+5)
      [Geo mean]                  120µs          119µs       -0.77%
      
      Reduce "spilled value remains" by 0.6% in cmd/go on AMD64.
      
      Change-Id: If655df343b0f30d1a49ab1ab644f10c698b96f3e
      Reviewed-on: https://go-review.googlesource.com/32442
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      348275cd
    • Elias Naur's avatar
      runtime: handle SIGPIPE in c-archive and c-shared programs · d24b57a6
      Elias Naur authored
      Before this CL, Go programs in c-archive or c-shared buildmodes
      would not handle SIGPIPE. That leads to surprising behaviour where
      writes on a closed pipe or socket would raise SIGPIPE and terminate
      the program. This CL changes the Go runtime to handle
      SIGPIPE regardless of buildmode. In addition, SIGPIPE from non-Go
      code is forwarded.
      
      Fixes #17393
      Updates #16760
      
      Change-Id: I155e82020a03a5cdc627a147c27da395662c3fe8
      Reviewed-on: https://go-review.googlesource.com/32796
      Run-TryBot: Elias Naur <elias.naur@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      d24b57a6
    • Robert Griesemer's avatar
      go/types: look at underlying type of element type of composite literals with elided types · e54662dc
      Robert Griesemer authored
      Match behavior of gc and gccgo.
      
      For #17954.
      
      Change-Id: I3f065e56d0a623bd7642c1438d0cab94d23fa2ae
      Reviewed-on: https://go-review.googlesource.com/33358Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      e54662dc
  6. 17 Nov, 2016 14 commits