1. 07 Feb, 2017 2 commits
  2. 06 Feb, 2017 3 commits
  3. 02 Feb, 2017 1 commit
  4. 01 Feb, 2017 1 commit
  5. 31 Jan, 2017 1 commit
    • Russ Cox's avatar
      [release-branch.go1.8] all: final merge of master into Go 1.8 release branch · d8d2f036
      Russ Cox authored
      After this, we will merge some of the dev work like
      type aliases and inlining into master, so any additional
      changes for the Go 1.8 release will need to be cherry-picked,
      not merged.
      
      3e55059f cmd/dist: really skip the testsanitizers tests on Android
      09496599 runtime: add explicit (void) in C to avoid GCC 7 problem
      4cffe2b6 cmd/dist: use the target GOOS to skip the test for issue 18153
      6bdb0c11 doc: update go1.8 release notes after TxOptions change
      09096bd3 cmd/go: update alldocs after CL 35150
      96ea0918 cmd/compile: use CMPWU for 32-bit or smaller unsigned Geq on ppc64{,le}
      21a8db1c doc: document go1.7.5
      
      Change-Id: I9e6a30c3fac43d4d4d15e93054ac00964c3ee958
      d8d2f036
  6. 30 Jan, 2017 2 commits
  7. 29 Jan, 2017 2 commits
  8. 28 Jan, 2017 1 commit
  9. 27 Jan, 2017 1 commit
  10. 26 Jan, 2017 6 commits
  11. 25 Jan, 2017 2 commits
  12. 24 Jan, 2017 7 commits
  13. 23 Jan, 2017 1 commit
    • Keith Randall's avatar
      runtime: amd64, use 4-byte ops for memmove of 4 bytes · a96e117a
      Keith Randall authored
      memmove used to use 2 2-byte load/store pairs to move 4 bytes.
      When the result is loaded with a single 4-byte load, it caused
      a store to load fowarding stall.  To avoid the stall,
      special case memmove to use 4 byte ops for the 4 byte copy case.
      
      We already have a special case for 8-byte copies.
      386 already specializes 4-byte copies.
      I'll do 2-byte copies also, but not for 1.8.
      
      benchmark                 old ns/op     new ns/op     delta
      BenchmarkIssue18740-8     7567          4799          -36.58%
      
      3-byte copies get a bit slower.  Other copies are unchanged.
      name         old time/op   new time/op   delta
      Memmove/3-8   4.76ns ± 5%   5.26ns ± 3%  +10.50%  (p=0.000 n=10+10)
      
      Fixes #18740
      
      Change-Id: Iec82cbac0ecfee80fa3c8fc83828f9a1819c3c74
      Reviewed-on: https://go-review.googlesource.com/35567
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      a96e117a
  14. 21 Jan, 2017 1 commit
  15. 20 Jan, 2017 4 commits
  16. 19 Jan, 2017 4 commits
  17. 18 Jan, 2017 1 commit
    • Austin Clements's avatar
      runtime: force workers out before checking mark roots · c1730ae4
      Austin Clements authored
      Currently we check that all roots are marked as soon as gcMarkDone
      decides to transition from mark 1 to mark 2. However, issue #16083
      indicates that there may be a race where we try to complete mark 1
      while a worker is still scanning a stack, causing the root mark check
      to fail.
      
      We don't yet understand this race, but as a simple mitigation, move
      the root check to after gcMarkDone performs a ragged barrier, which
      will force any remaining workers to finish their current job.
      
      Updates #16083. This may "fix" it, but it would be better to
      understand and fix the underlying race.
      
      Change-Id: I1af9ce67bd87ade7bc2a067295d79c28cd11abd2
      Reviewed-on: https://go-review.googlesource.com/35353
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      c1730ae4