1. 21 Apr, 2016 21 commits
    • Matthew Dempsky's avatar
      cmd/compile: split TSLICE into separate Type kind · 40f1d0ca
      Matthew Dempsky authored
      Instead of using TARRAY for both arrays and slices, create a new
      TSLICE kind to handle slices.
      
      Also, get rid of the "DDDArray" distinction. While kinda ugly, it
      seems likely we'll need to defer evaluating the constant bounds
      expressions for golang.org/issue/13890.
      
      Passes toolstash/buildall.
      
      Change-Id: I8e45d4900e7df3a04cce59428ec8b38035d3cc3a
      Reviewed-on: https://go-review.googlesource.com/22329Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      40f1d0ca
    • Robert Griesemer's avatar
      spec: fix incorrect comment in shift example · 5213cd70
      Robert Griesemer authored
      - adjusted example code
      - fixed comments
      
      Fixes #14785.
      
      Change-Id: Ia757dc93b0a69b8408559885ece7f3685a37daaa
      Reviewed-on: https://go-review.googlesource.com/22353Reviewed-by: default avatarRob Pike <r@golang.org>
      5213cd70
    • Austin Clements's avatar
      runtime: eliminate floating garbage estimate · c8bd293e
      Austin Clements authored
      Currently when we compute the trigger for the next GC, we do it based
      on an estimate of the reachable heap size at the start of the GC
      cycle, which is itself based on an estimate of the floating garbage.
      This was introduced by 4655aadd to fix a bad feedback loop that allowed
      the heap to grow to many times the true reachable size.
      
      However, this estimate gets easily confused by rapidly allocating
      applications, and, worse it's different than the heap size the trigger
      controller uses to compute the trigger itself. This results in the
      trigger controller often thinking that GC finished before it started.
      Since this would be a pretty great outcome from it's perspective, it
      sets the trigger for the next cycle as close to the next goal as
      possible (which is limited to 95% of the goal).
      
      Furthermore, the bad feedback loop this estimate originally fixed
      seems not to happen any more, suggesting it was fixed more correctly
      by some other change in the mean time. Finally, with the change to
      allocate black, it shouldn't even be theoretically possible for this
      bad feedback loop to occur.
      
      Hence, eliminate the floating garbage estimate and simply consider the
      reachable heap to be the marked heap. This harms overall throughput
      slightly for allocation-heavy benchmarks, but significantly improves
      mutator availability.
      
      Fixes #12204. This brings the average trigger in this benchmark from
      0.95 (the cap) to 0.7 and the active GC utilization from ~90% to ~45%.
      
      Updates #14951. This makes the trigger controller much better behaved,
      so it pulls the trigger lower if assists are consuming a lot of CPU
      like it's supposed to, increasing mutator availability.
      
      name              old time/op  new time/op  delta
      XBenchGarbage-12  2.21ms ± 1%  2.28ms ± 3%  +3.29%  (p=0.000 n=17+17)
      
      Some of this slow down we paid for in earlier commits. Relative to the
      start of the series to switch to allocate-black (the parent of "count
      black allocations toward scan work"), the garbage benchmark is 2.62%
      slower.
      
      name                      old time/op    new time/op    delta
      BinaryTree17-12              2.53s ± 3%     2.53s ± 3%    ~     (p=0.708 n=20+19)
      Fannkuch11-12                2.08s ± 0%     2.08s ± 0%  -0.22%  (p=0.002 n=19+18)
      FmtFprintfEmpty-12          45.3ns ± 2%    45.2ns ± 3%    ~     (p=0.505 n=20+20)
      FmtFprintfString-12          129ns ± 0%     131ns ± 2%  +1.80%  (p=0.000 n=16+19)
      FmtFprintfInt-12             121ns ± 2%     121ns ± 2%    ~     (p=0.768 n=19+19)
      FmtFprintfIntInt-12          186ns ± 1%     188ns ± 3%  +0.99%  (p=0.000 n=19+19)
      FmtFprintfPrefixedInt-12     188ns ± 1%     188ns ± 1%    ~     (p=0.947 n=18+16)
      FmtFprintfFloat-12           254ns ± 1%     255ns ± 1%  +0.30%  (p=0.002 n=19+17)
      FmtManyArgs-12               763ns ± 0%     770ns ± 0%  +0.92%  (p=0.000 n=18+18)
      GobDecode-12                7.00ms ± 1%    7.04ms ± 1%  +0.61%  (p=0.049 n=20+20)
      GobEncode-12                5.88ms ± 1%    5.88ms ± 0%    ~     (p=0.641 n=18+19)
      Gzip-12                      214ms ± 1%     215ms ± 1%  +0.43%  (p=0.002 n=18+19)
      Gunzip-12                   37.6ms ± 0%    37.6ms ± 0%  +0.11%  (p=0.015 n=17+18)
      HTTPClientServer-12         76.9µs ± 2%    78.1µs ± 2%  +1.44%  (p=0.000 n=20+18)
      JSONEncode-12               15.2ms ± 2%    15.1ms ± 1%    ~     (p=0.271 n=19+18)
      JSONDecode-12               53.1ms ± 1%    53.3ms ± 0%  +0.49%  (p=0.000 n=18+19)
      Mandelbrot200-12            4.04ms ± 1%    4.03ms ± 0%  -0.33%  (p=0.005 n=18+18)
      GoParse-12                  3.29ms ± 1%    3.28ms ± 1%    ~     (p=0.146 n=16+17)
      RegexpMatchEasy0_32-12      69.9ns ± 3%    69.5ns ± 1%    ~     (p=0.785 n=20+19)
      RegexpMatchEasy0_1K-12       237ns ± 0%     237ns ± 0%    ~     (p=1.000 n=18+18)
      RegexpMatchEasy1_32-12      69.5ns ± 1%    69.2ns ± 1%  -0.44%  (p=0.020 n=16+19)
      RegexpMatchEasy1_1K-12       372ns ± 1%     371ns ± 2%    ~     (p=0.086 n=20+19)
      RegexpMatchMedium_32-12      108ns ± 3%     107ns ± 1%  -1.00%  (p=0.004 n=19+14)
      RegexpMatchMedium_1K-12     34.2µs ± 4%    34.0µs ± 2%    ~     (p=0.380 n=19+20)
      RegexpMatchHard_32-12       1.77µs ± 4%    1.76µs ± 3%    ~     (p=0.558 n=18+20)
      RegexpMatchHard_1K-12       53.4µs ± 4%    52.8µs ± 2%  -1.10%  (p=0.020 n=18+20)
      Revcomp-12                   359ms ± 4%     377ms ± 0%  +5.19%  (p=0.000 n=20+18)
      Template-12                 63.7ms ± 2%    62.9ms ± 2%  -1.27%  (p=0.005 n=18+20)
      TimeParse-12                 316ns ± 2%     313ns ± 1%    ~     (p=0.059 n=20+16)
      TimeFormat-12                329ns ± 0%     331ns ± 0%  +0.39%  (p=0.000 n=16+18)
      [Geo mean]                  51.6µs         51.7µs       +0.18%
      
      Change-Id: I1dce4640c8205d41717943b021039fffea863c57
      Reviewed-on: https://go-review.googlesource.com/21324Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      c8bd293e
    • Austin Clements's avatar
      runtime: allocate black during GC · 6002e01e
      Austin Clements authored
      Currently we allocate white for most of concurrent marking. This is
      based on the classical argument that it produces less floating
      garbage, since allocations during GC may not get linked into the heap
      and allocating white lets us reclaim these. However, it's not clear
      how often this actually happens, especially since our write barrier
      shades any pointer as soon as it's installed in the heap regardless of
      the color of the slot.
      
      On the other hand, allocating black has several advantages that seem
      to significantly outweigh this downside.
      
      1) It naturally bounds the total scan work to the live heap size at
      the start of a GC cycle. Allocating white does not, and thus depends
      entirely on assists to prevent the heap from growing faster than it
      can be scanned.
      
      2) It reduces the total amount of scan work per GC cycle by the size
      of newly allocated objects that are linked into the heap graph, since
      objects allocated black never need to be scanned.
      
      3) It reduces total write barrier work since more objects will already
      be black when they are linked into the heap graph.
      
      This gives a slight overall improvement in benchmarks.
      
      name              old time/op  new time/op  delta
      XBenchGarbage-12  2.24ms ± 0%  2.21ms ± 1%  -1.32%  (p=0.000 n=18+17)
      
      name                      old time/op    new time/op    delta
      BinaryTree17-12              2.60s ± 3%     2.53s ± 3%  -2.56%  (p=0.000 n=20+20)
      Fannkuch11-12                2.08s ± 1%     2.08s ± 0%    ~     (p=0.452 n=19+19)
      FmtFprintfEmpty-12          45.1ns ± 2%    45.3ns ± 2%    ~     (p=0.367 n=19+20)
      FmtFprintfString-12          131ns ± 3%     129ns ± 0%  -1.60%  (p=0.000 n=20+16)
      FmtFprintfInt-12             122ns ± 0%     121ns ± 2%  -0.86%  (p=0.000 n=16+19)
      FmtFprintfIntInt-12          187ns ± 1%     186ns ± 1%    ~     (p=0.514 n=18+19)
      FmtFprintfPrefixedInt-12     189ns ± 0%     188ns ± 1%  -0.54%  (p=0.000 n=16+18)
      FmtFprintfFloat-12           256ns ± 0%     254ns ± 1%  -0.43%  (p=0.000 n=17+19)
      FmtManyArgs-12               769ns ± 0%     763ns ± 0%  -0.72%  (p=0.000 n=18+18)
      GobDecode-12                7.08ms ± 2%    7.00ms ± 1%  -1.22%  (p=0.000 n=20+20)
      GobEncode-12                5.88ms ± 0%    5.88ms ± 1%    ~     (p=0.406 n=18+18)
      Gzip-12                      214ms ± 0%     214ms ± 1%    ~     (p=0.103 n=17+18)
      Gunzip-12                   37.6ms ± 0%    37.6ms ± 0%    ~     (p=0.563 n=17+17)
      HTTPClientServer-12         77.2µs ± 3%    76.9µs ± 2%    ~     (p=0.606 n=20+20)
      JSONEncode-12               15.1ms ± 1%    15.2ms ± 2%    ~     (p=0.138 n=19+19)
      JSONDecode-12               53.3ms ± 1%    53.1ms ± 1%  -0.33%  (p=0.000 n=19+18)
      Mandelbrot200-12            4.04ms ± 1%    4.04ms ± 1%    ~     (p=0.075 n=19+18)
      GoParse-12                  3.30ms ± 1%    3.29ms ± 1%  -0.57%  (p=0.000 n=18+16)
      RegexpMatchEasy0_32-12      69.5ns ± 1%    69.9ns ± 3%    ~     (p=0.822 n=18+20)
      RegexpMatchEasy0_1K-12       237ns ± 1%     237ns ± 0%    ~     (p=0.398 n=19+18)
      RegexpMatchEasy1_32-12      69.8ns ± 2%    69.5ns ± 1%    ~     (p=0.090 n=20+16)
      RegexpMatchEasy1_1K-12       371ns ± 1%     372ns ± 1%    ~     (p=0.178 n=19+20)
      RegexpMatchMedium_32-12      108ns ± 2%     108ns ± 3%    ~     (p=0.124 n=20+19)
      RegexpMatchMedium_1K-12     33.9µs ± 2%    34.2µs ± 4%    ~     (p=0.309 n=20+19)
      RegexpMatchHard_32-12       1.75µs ± 2%    1.77µs ± 4%  +1.28%  (p=0.018 n=19+18)
      RegexpMatchHard_1K-12       52.7µs ± 1%    53.4µs ± 4%  +1.23%  (p=0.013 n=15+18)
      Revcomp-12                   354ms ± 1%     359ms ± 4%  +1.27%  (p=0.043 n=20+20)
      Template-12                 63.6ms ± 2%    63.7ms ± 2%    ~     (p=0.654 n=20+18)
      TimeParse-12                 313ns ± 1%     316ns ± 2%  +0.80%  (p=0.014 n=17+20)
      TimeFormat-12                332ns ± 0%     329ns ± 0%  -0.66%  (p=0.000 n=16+16)
      [Geo mean]                  51.7µs         51.6µs       -0.09%
      
      Change-Id: I2214a6a0e4f544699ea166073249a8efdf080dc0
      Reviewed-on: https://go-review.googlesource.com/21323Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      6002e01e
    • Austin Clements's avatar
      runtime: simplify/optimize allocate-black a bit · 64a26b79
      Austin Clements authored
      Currently allocating black switches to the system stack (which is
      probably a historical accident) and atomically updates the global
      bytes marked stat. Since we're about to depend on this much more,
      optimize it a bit by putting it back on the regular stack and updating
      the per-P bytes marked stat, which gets lazily folded into the global
      bytes marked stat.
      
      Change-Id: Ibbe16e5382d3fd2256e4381f88af342bf7020b04
      Reviewed-on: https://go-review.googlesource.com/22170Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      64a26b79
    • Austin Clements's avatar
      runtime: count black allocations toward scan work · 479501c1
      Austin Clements authored
      Currently we count black allocations toward the scannable heap size,
      but not toward the scan work we've done so far. This is clearly
      inconsistent (we have, in effect, scanned these allocations and since
      they're already black, we're not going to scan them again). Worse, it
      means we don't count black allocations toward the scannable heap size
      as of the *next* GC because this is based on the amount of scan work
      we did in this cycle.
      
      Fix this by counting black allocations as scan work. Currently the GC
      spends very little time in allocate-black mode, so this probably
      hasn't been a problem, but this will become important when we switch
      to always allocating black.
      
      Change-Id: If6ff693b070c385b65b6ecbbbbf76283a0f9d990
      Reviewed-on: https://go-review.googlesource.com/22119Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      479501c1
    • Marcel van Lohuizen's avatar
      testing: add matching of subtest · a683c385
      Marcel van Lohuizen authored
      Allows passing regexps per subtest to --test.run and --test.bench
      
      Note that the documentation explicitly states that the split regular
      expressions match the correpsonding parts (path components) of
      the bench/test identifier. This is intended and slightly different
      from the i'th RE matching the subtest/subbench at the respective
      level.  Picking this semantics allows guaranteeing that a test or
      benchmark identifier as printed by go test can be passed verbatim
      (possibly quoted) to, respectively, -run or -bench: subtests and
      subbenches might have a '/' in their name, causing a misaligment if
      their ID is passed to -run or -bench as is.
      This semantics has other benefits, but this is the main motivation.
      
      Fixes golang.go#15126
      
      Change-Id: If72e6d3f54db1df6bc2729ac6edc7ab3c740e7c3
      Reviewed-on: https://go-review.googlesource.com/19122Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      a683c385
    • Keith Randall's avatar
      cmd/compile: handle mem copies in amd64 backend · f8fc3710
      Keith Randall authored
      Fixes noopt builder.
      
      Change-Id: If13373b2597f0fcc9b1b2f9c860f2bd043e43c6c
      Reviewed-on: https://go-review.googlesource.com/22338Reviewed-by: default avatarKeith Randall <khr@golang.org>
      f8fc3710
    • Cherry Zhang's avatar
      cmd/compile/internal/gc: fix return value offset for SSA backend on ARM · 508a424e
      Cherry Zhang authored
      Progress on SSA backend for ARM. Still not complete. It compiles a
      Fibonacci function, but the caller picked the return value from an
      incorrect offset. This CL adjusts it to match the stack frame layout
      for architectures with link register.
      
      Updates #15365.
      
      Change-Id: I01e03c3e95f5503a185e8ac2b6d9caf4faf3d014
      Reviewed-on: https://go-review.googlesource.com/22186Reviewed-by: default avatarKeith Randall <khr@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      508a424e
    • Cherry Zhang's avatar
      cmd/compile/internal/arm: fix comparison & conditional branch for SSA on ARM · 7c6b48ff
      Cherry Zhang authored
      Progress on SSA for ARM. Still not complete. Now Fibonacci function compiles
      and runs correctly.
      
      The old backend swaps the operands for CMP instruction. This CL does the same
      on SSA backend, and uses conditional branch accordingly.
      
      Updates #15365.
      
      Change-Id: I117e17feb22f03d936608bd232f76970e4bbe21a
      Reviewed-on: https://go-review.googlesource.com/22187Reviewed-by: default avatarKeith Randall <khr@golang.org>
      7c6b48ff
    • David Crawshaw's avatar
      cmd/link: convert textp into a slice · 7d56215b
      David Crawshaw authored
      Updates #15374
      
      Change-Id: I3ea715735862fe9550b88d7a29def6cb9d4419a6
      Reviewed-on: https://go-review.googlesource.com/22243
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMichael Hudson-Doyle <michael.hudson@canonical.com>
      7d56215b
    • David Crawshaw's avatar
      cmd/link: calculate section alignment concurrently · 5a0881a1
      David Crawshaw authored
      Reduces link time for cmd/go by 1%.
      
      Change-Id: Iad4a16db0aedc56f81ddf73ba9b632e418dc1b19
      Reviewed-on: https://go-review.googlesource.com/22242Reviewed-by: default avatarMichael Hudson-Doyle <michael.hudson@canonical.com>
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      5a0881a1
    • Alex Brainman's avatar
      debug/pe: introduce Section.Relocs · 45522a6a
      Alex Brainman authored
      cmd/link reads PE object files when building programs with cgo.
      cmd/link accesses object relocations. Add new Section.Relocs that
      provides similar functionality in debug/pe.
      
      Updates #15345
      
      Change-Id: I34de91b7f18cf1c9e4cdb3aedd685486a625ac92
      Reviewed-on: https://go-review.googlesource.com/22332
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAlex Brainman <alex.brainman@gmail.com>
      45522a6a
    • Keith Randall's avatar
      cmd/compile: fix ssa/check/on build · e4843488
      Keith Randall authored
      Disable phielimValue from rewrite pass for now.
      
      Change-Id: I9f3bb1f527b50bc7a21cc6b7cb89f6136efd81e8
      Reviewed-on: https://go-review.googlesource.com/22335
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      e4843488
    • Martin Möhrmann's avatar
      runtime: use type int to specify size for newarray · 7e460e70
      Martin Möhrmann authored
      Consistently use type int for the size argument of
      runtime.newarray, runtime.reflect_unsafe_NewArray
      and reflect.unsafe_NewArray.
      
      Change-Id: Ic77bf2dde216c92ca8c49462f8eedc0385b6314e
      Reviewed-on: https://go-review.googlesource.com/22311Reviewed-by: default avatarKeith Randall <khr@golang.org>
      Run-TryBot: Martin Möhrmann <martisch@uos.de>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      7e460e70
    • Keith Randall's avatar
      cmd/compile: fix dominator check in check() · 4938d7b5
      Keith Randall authored
      Ancestor comparison was the wrong way around, effectively
      disabling the def-must-dominate-use check.
      
      Update #15084
      
      Change-Id: Ic56d674c5000569d2cc855bbb000a60eae517c7c
      Reviewed-on: https://go-review.googlesource.com/22330
      Run-TryBot: Keith Randall <khr@golang.org>
      Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      4938d7b5
    • David Crawshaw's avatar
      cmd/link: fix reordering of plt/rel · 9568d54f
      David Crawshaw authored
      For the Solaris and S/390 builders.
      
      Change-Id: Id9a83e0df91e6d0df8488ec5e2a546ba8e2d800e
      Reviewed-on: https://go-review.googlesource.com/22327
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMichael Hudson-Doyle <michael.hudson@canonical.com>
      Reviewed-by: default avatarMichael Munday <munday@ca.ibm.com>
      9568d54f
    • Alex Brainman's avatar
      debug/pe: update cstring documentation · 11f10410
      Alex Brainman authored
      Updates #15345
      
      Change-Id: If1fca1f6042571cb0ac689bbb3c294309dd6e7b4
      Reviewed-on: https://go-review.googlesource.com/22331Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      11f10410
    • Alex Brainman's avatar
      debug/pe: pretty section.go code · 285a1843
      Alex Brainman authored
      Introduce (*SectionHeader32).fullName and add documentation comments.
      
      Updates #15345
      
      Change-Id: I8f3b8ab9492642d62e7aad010c91c68daea3f14b
      Reviewed-on: https://go-review.googlesource.com/22301Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      285a1843
    • Tal Shprecher's avatar
      cmd/compile: reject embedded unsafe.Pointer values · 75b886ab
      Tal Shprecher authored
      Fixes #14729
      
      Change-Id: Ied819aa7b23e25de30aa8cde049c97297b4cab11
      Reviewed-on: https://go-review.googlesource.com/22325Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      75b886ab
    • Robert Griesemer's avatar
      cmd/compile: accept old and new import format for builtin declarations · f4f1b307
      Robert Griesemer authored
      Test with forceNewExport set to true (but continues to be disabled by
      default for now).
      
      Fixes #15322.
      
      Change-Id: I3b893db2206cbb79e66339284f22f4a0b20bf137
      Reviewed-on: https://go-review.googlesource.com/22328Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      f4f1b307
  2. 20 Apr, 2016 19 commits