1. 24 Jan, 2017 7 commits
  2. 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
  3. 21 Jan, 2017 1 commit
  4. 20 Jan, 2017 4 commits
  5. 19 Jan, 2017 2 commits
  6. 18 Jan, 2017 4 commits
  7. 17 Jan, 2017 4 commits
  8. 16 Jan, 2017 4 commits
  9. 14 Jan, 2017 4 commits
  10. 13 Jan, 2017 6 commits
    • Brad Fitzpatrick's avatar
      net/http: make sure Hijack's bufio.Reader includes pre-read background byte · b2a3b54b
      Brad Fitzpatrick authored
      Previously, if the Hijack called stopped the background read call
      which read a byte, that byte was sitting in memory, buffered, ready to
      be Read by Hijack's returned bufio.Reader, but it wasn't yet in the
      bufio.Reader's buffer itself, so bufio.Reader.Buffered() reported 1
      byte fewer.
      
      This matters for callers who wanted to stitch together any buffered
      data (with bufio.Reader.Peek(bufio.Reader.Buffered())) with Hijack's
      returned net.Conn. Otherwise there was no way for callers to know a
      byte was read.
      
      Change-Id: Id7cb0a0a33fe2f33d79250e13dbaa9c0f7abba13
      Reviewed-on: https://go-review.googlesource.com/35232
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJoe Tsai <thebrokentoaster@gmail.com>
      b2a3b54b
    • David Crawshaw's avatar
      cmd/go, misc: rework cwd handling for iOS tests · 593ea3b3
      David Crawshaw authored
      Another change in behvaior (bug) in LLDB. Despite the fact that
      LLDB can dump the symtab of our test binaries and show the function
      addresses, it can no longer call the functions. This means the chdir
      trick on signal is failing.
      
      This CL uses a new trick. For iOS, the exec script passes the change
      in directory as an argument, and it is processed early by the test
      harness generated by cmd/go.
      
      For the iOS builders.
      
      Change-Id: I8f5d0f831fe18de99f097761f89c5184d5bf2afb
      Reviewed-on: https://go-review.googlesource.com/35152Reviewed-by: default avatarElias Naur <elias.naur@gmail.com>
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      593ea3b3
    • Michael Munday's avatar
      syscall: export Fsid.X__val on s390x · 0642b8a2
      Michael Munday authored
      mkpost.go replaces all variables prefixed with 'X_' with '_' on s390x
      because most of them do not need to be exposed. X__val is being used
      by a third party library so it turns out we do need to expose it on
      s390x (it is already exposed on all other Linux architectures).
      
      Fixes #17298 and updates #18632.
      
      Change-Id: Ic03463229a5f75ca41a4a4b50300da4b4d892d45
      Reviewed-on: https://go-review.googlesource.com/30130Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      0642b8a2
    • Alberto Donizetti's avatar
      doc/gdb: mention GOTRACEBACK=crash · 4601eae6
      Alberto Donizetti authored
      Also fix a couple of other errors.
      
      Fixes #6877
      
      Change-Id: I94c81c5847cc7b0adab19418e71687bc2ee7fe94
      Reviewed-on: https://go-review.googlesource.com/34960Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      4601eae6
    • Keith Randall's avatar
      misc/cgo/testplugin: test that types and itabs are unique · 4c4c5fc7
      Keith Randall authored
      Make sure that the same type and itab generated in two
      different plugins are actually the same thing.
      
      See also CL 35115
      
      Change-Id: I0c1ecb039d7e2bf5a601d58dfa162a435ae4ef76
      Reviewed-on: https://go-review.googlesource.com/35116
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      4c4c5fc7
    • Austin Clements's avatar
      reflect: keep makeFuncImpl live across makeFuncStub · 22689c44
      Austin Clements authored
      When traceback sees reflect.makeFuncStub (or reflect.methodValueCall)
      on the stack, it expects to be able to get the *reflect.makeFuncImpl
      (or *reflect.methodValue) for that call from the first outgoing
      argument slot of makeFuncStub/methodValueCall.
      
      However, currently this object isn't necessarily kept live across
      makeFuncStub. This means it may get garbage collected while in a
      reflect call and reused for something else. If we then try to
      traceback, the runtime will see a corrupted makeFuncImpl object and
      panic. This was not a problem in previous releases because we always
      kept arguments live across the whole function. This became a problem
      when we stopped doing this.
      
      Fix this by using reflect.KeepAlive to keep the
      makeFuncImpl/methodValue live across all of callReflect/callMethod,
      which in turn keeps it live as long as makeFuncStub/methodValueCall
      are on the stack.
      
      Fixes #18635.
      
      Change-Id: I91853efcf17912390fddedfb0230648391c33936
      Reviewed-on: https://go-review.googlesource.com/35151
      Run-TryBot: Austin Clements <austin@google.com>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      22689c44
  11. 12 Jan, 2017 3 commits
    • David Crawshaw's avatar
      cmd/link: only exclude C-only symbols on darwin · 9cf06ed6
      David Crawshaw authored
      C-only symbols are excluded from pclntab because of a quirk of darwin,
      where functions are referred to by an exported symbol so dynamic
      relocations de-duplicate to the host binary module and break unwinding.
      
      This doesn't happen on ELF systems because the linker always refers to
      unexported module-local symbols, so we don't need this condition.
      And the current logic for excluding some functions breaks the module
      verification code in moduledataverify1. So disable this for plugins
      on linux.
      
      (In 1.9, it will probably be necessary to introduce a module-local
      symbol reference system on darwin to fix a different bug, so all of
      this onlycsymbol code made be short-lived.)
      
      With this CL, the tests in CL 35116 pass.
      
      Change-Id: I517d7ca4427241fa0a91276c462827efb9383be9
      Reviewed-on: https://go-review.googlesource.com/35190Reviewed-by: default avatarMichael Hudson-Doyle <michael.hudson@canonical.com>
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      9cf06ed6
    • Joe Tsai's avatar
      compress/flate: avoid large stack growth in fillDeflate · 9c3630f5
      Joe Tsai authored
      Ranging over an array causes the array to be copied over to the
      stack, which cause large re-growths. Instead, we should iterate
      over slices of the array.
      
      Also, assigning a large struct literal uses the stack even
      though the actual fields being populated are small in comparison
      to the entirety of the struct (see #18636).
      
      Fixing the stack growth does not alter CPU-time performance much
      since the stack-growth and copying was such a tiny portion of the
      compression work:
      
      name                         old time/op    new time/op    delta
      Encode/Digits/Default/1e4-8     332µs ± 1%     332µs ± 1%   ~     (p=0.796 n=10+10)
      Encode/Digits/Default/1e5-8    5.07ms ± 2%    5.05ms ± 1%   ~       (p=0.815 n=9+8)
      Encode/Digits/Default/1e6-8    53.7ms ± 1%    53.9ms ± 1%   ~     (p=0.075 n=10+10)
      Encode/Twain/Default/1e4-8      380µs ± 1%     380µs ± 1%   ~     (p=0.684 n=10+10)
      Encode/Twain/Default/1e5-8     5.79ms ± 2%    5.79ms ± 1%   ~      (p=0.497 n=9+10)
      Encode/Twain/Default/1e6-8     61.5ms ± 1%    61.8ms ± 1%   ~     (p=0.247 n=10+10)
      
      name                         old speed      new speed      delta
      Encode/Digits/Default/1e4-8  30.1MB/s ± 1%  30.1MB/s ± 1%   ~     (p=0.753 n=10+10)
      Encode/Digits/Default/1e5-8  19.7MB/s ± 2%  19.8MB/s ± 1%   ~       (p=0.795 n=9+8)
      Encode/Digits/Default/1e6-8  18.6MB/s ± 1%  18.5MB/s ± 1%   ~     (p=0.072 n=10+10)
      Encode/Twain/Default/1e4-8   26.3MB/s ± 1%  26.3MB/s ± 1%   ~     (p=0.616 n=10+10)
      Encode/Twain/Default/1e5-8   17.3MB/s ± 2%  17.3MB/s ± 1%   ~      (p=0.484 n=9+10)
      Encode/Twain/Default/1e6-8   16.3MB/s ± 1%  16.2MB/s ± 1%   ~     (p=0.238 n=10+10)
      
      Updates #18636
      Fixes #18625
      
      Change-Id: I471b20339bf675f63dc56d38b3acdd824fe23328
      Reviewed-on: https://go-review.googlesource.com/35122Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      9c3630f5
    • David Crawshaw's avatar
      cmd/go: add comment about SIGUSR2 on iOS · 4f0aac52
      David Crawshaw authored
      Missing from CL 34926.
      
      Change-Id: I4a046440c30811f26da53bee0e853dae3b0ac57a
      Reviewed-on: https://go-review.googlesource.com/35123Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      4f0aac52