1. 05 Aug, 2016 4 commits
  2. 04 Aug, 2016 2 commits
    • Brad Fitzpatrick's avatar
      syscall: fix Gettimeofday on macOS Sierra · da070bed
      Brad Fitzpatrick authored
      Fixes #16606
      
      Change-Id: I57465061b90e901293cd8b6ef756d6aa84ebd4a3
      Reviewed-on: https://go-review.googlesource.com/25495Reviewed-by: 's avatarQuentin Smith <quentin@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Quentin Smith <quentin@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      da070bed
    • David Crawshaw's avatar
      runtime: initialize hash algs before typemap · f135c326
      David Crawshaw authored
      When compiling with -buildmode=shared, a map[int32]*_type is created for
      each extra module mapping duplicate types back to a canonical object.
      This is done in the function typelinksinit, which is called before the
      init function that sets up the hash functions for the map
      implementation. The result is typemap becomes unusable after
      runtime initialization.
      
      The fix in this CL is to move algorithm init before typelinksinit in
      the runtime setup process. (For 1.8, we may want to turn typemap into
      a sorted slice of types and use binary search.)
      
      Manually tested on GOOS=linux with:
      
      	GOHOSTARCH=386 GOARCH=386 ./make.bash && \
      		go install -buildmode=shared std && \
      		cd ../test && \
      		go run run.go -linkshared
      
      Fixes #16590
      
      Change-Id: Idc08c50cc70d20028276fbf564509d2cd5405210
      Reviewed-on: https://go-review.googlesource.com/25469
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      f135c326
  3. 02 Aug, 2016 10 commits
  4. 29 Jul, 2016 1 commit
    • Cherry Zhang's avatar
      cmd/compile: fix possible spill of invalid pointer with DUFFZERO on AMD64 · 111d590f
      Cherry Zhang authored
      SSA compiler on AMD64 may spill Duff-adjusted address as scalar. If
      the object is on stack and the stack moves, the spilled address become
      invalid.
      
      Making the spill pointer-typed does not work. The Duff-adjusted address
      points to the memory before the area to be zeroed and may be invalid.
      This may cause stack scanning code panic.
      
      Fix it by doing Duff-adjustment in genValue, so the intermediate value
      is not seen by the reg allocator, and will not be spilled.
      
      Add a test to cover both cases. As it depends on allocation, it may
      be not always triggered.
      
      Fixes #16515.
      
      Change-Id: Ia81d60204782de7405b7046165ad063384ede0db
      Reviewed-on: https://go-review.googlesource.com/25309
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      111d590f
  5. 28 Jul, 2016 1 commit
  6. 27 Jul, 2016 2 commits
    • Rhys Hiltner's avatar
      runtime: reduce GC assist extra credit · ccca9c9c
      Rhys Hiltner authored
      Mutator goroutines that allocate memory during the concurrent mark
      phase are required to spend some time assisting the garbage
      collector. The magnitude of this mandatory assistance is proportional
      to the goroutine's allocation debt and subject to the assistance
      ratio as calculated by the pacer.
      
      When assisting the garbage collector, a mutator goroutine will go
      beyond paying off its allocation debt. It will build up extra credit
      to amortize the overhead of the assist.
      
      In fast-allocating applications with high assist ratios, building up
      this credit can take the affected goroutine's entire time slice.
      Reduce the penalty on each goroutine being selected to assist the GC
      in two ways, to spread the responsibility more evenly.
      
      First, do a consistent amount of extra scan work without regard for
      the pacer's assistance ratio. Second, reduce the magnitude of the
      extra scan work so it can be completed within a few hundred
      microseconds.
      
      Commentary on gcOverAssistWork is by Austin Clements, originally in
      https://golang.org/cl/24704
      
      Updates #14812
      Fixes #16432
      
      Change-Id: I436f899e778c20daa314f3e9f0e2a1bbd53b43e1
      Reviewed-on: https://go-review.googlesource.com/25155
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      Reviewed-by: 's avatarChris Broadfoot <cbro@golang.org>
      ccca9c9c
    • Brad Fitzpatrick's avatar
      net/http: fix data race with concurrent use of Server.Serve · c80e0d37
      Brad Fitzpatrick authored
      Fixes #16505
      
      Change-Id: I0afabcc8b1be3a5dbee59946b0c44d4c00a28d71
      Reviewed-on: https://go-review.googlesource.com/25280
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarChris Broadfoot <cbro@golang.org>
      c80e0d37
  7. 26 Jul, 2016 7 commits
  8. 25 Jul, 2016 1 commit
  9. 22 Jul, 2016 1 commit
  10. 21 Jul, 2016 6 commits
    • Chris Broadfoot's avatar
      go1.7rc3 · 8707f31c
      Chris Broadfoot authored
      Change-Id: Iaef13003979c68926c260c415d6074a50ae137b2
      Reviewed-on: https://go-review.googlesource.com/25142
      Run-TryBot: Chris Broadfoot <cbro@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      8707f31c
    • Chris Broadfoot's avatar
      all: merge master into release-branch.go1.7 · 16a2af03
      Chris Broadfoot authored
      Change-Id: I2511c3f7583887b641c9b3694aae54789fbc5342
      16a2af03
    • Brad Fitzpatrick's avatar
      misc/trace: disable trace resolution warning · 243d51f0
      Brad Fitzpatrick authored
      It was removed in upstream Chrome https://codereview.chromium.org/2016863004
      
      Rather than update to the latest version, make the minimal change for Go 1.7 and
      change the "showToUser" boolean from true to false.
      
      Tested by hand that it goes away after this change.
      
      Updates #16247
      
      Change-Id: I051f49da878e554b1a34a88e9abc70ab50e18780
      Reviewed-on: https://go-review.googlesource.com/25117Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      243d51f0
    • David Chase's avatar
      cmd/compile: change phi location to be optimistic at backedges · 846bc6c5
      David Chase authored
      This is:
      
      (1) a simple trick that cuts the number of phi-nodes
      (temporarily) inserted into the ssa representation by a factor
      of 10, and can cut the user time to compile tricky inputs like
      gogo/protobuf tests from 13 user minutes to 9.5, and memory
      allocation from 3.4GB to 2.4GB.
      
      (2) a fix to sparse lookup, that does not rely on
      an assumption proven false by at least one pathological
      input "etldlen".
      
      These two changes fix unrelated compiler performance bugs,
      both necessary to obtain good performance compiling etldlen.
      Without them it takes 20 minutes or longer, with them it
      completes in 2 minutes, without a gigantic memory footprint.
      
      Updates #16407
      
      Change-Id: Iaa8aaa8c706858b3d49de1c4865a7fd79e6f4ff7
      Reviewed-on: https://go-review.googlesource.com/23136Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      846bc6c5
    • Keith Randall's avatar
      cmd/compile: move phi args which are constants closer to the phi · 305a0ac1
      Keith Randall authored
      entry:
         x = MOVQconst [7]
         ...
      b1:
         goto b2
      b2:
         v = Phi(x, y, z)
      
      Transform that program to:
      
      entry:
         ...
      b1:
         x = MOVQconst [7]
         goto b2
      b2:
         v = Phi(x, y, z)
      
      This CL moves constant-generating instructions used by a phi to the
      appropriate immediate predecessor of the phi's block.
      
      We used to put all constants in the entry block.  Unfortunately, in
      large functions we have lots of constants at the start of the
      function, all of which are used by lots of phis throughout the
      function.  This leads to the constants being live through most of the
      function (especially if there is an outer loop).  That's an O(n^2)
      problem.
      
      Note that most of the non-phi uses of constants have already been
      folded into instructions (ADDQconst, MOVQstoreconst, etc.).
      
      This CL may be generally useful for other instances of compiler
      slowness, I'll have to check.  It may cause some programs to run
      slower, but probably not by much, as rematerializeable values like
      these constants are allocated late (not at their originally scheduled
      location) anyway.
      
      This CL is definitely a minimal change that can be considered for 1.7.
      We probably want to do a better job in the tighten pass generally, not
      just for phi args.  Leaving that for 1.8.
      
      Update #16407
      
      Change-Id: If112a8883b4ef172b2f37dea13e44bda9346c342
      Reviewed-on: https://go-review.googlesource.com/25046
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
      305a0ac1
    • Ian Lance Taylor's avatar
      runtime: add explicit `INT $3` at end of Darwin amd64 sigtramp · ff227b8a
      Ian Lance Taylor authored
      The omission of this instruction could confuse the traceback code if a
      SIGPROF occurred during a signal handler.  The traceback code would
      trace up to sigtramp, but would then get confused because it would see a
      PC address that did not appear to be in the function.
      
      Fixes #16453.
      
      Change-Id: I2b3d53e0b272fb01d9c2cb8add22bad879d3eebc
      Reviewed-on: https://go-review.googlesource.com/25104Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
      ff227b8a
  11. 20 Jul, 2016 4 commits
    • Austin Clements's avatar
      runtime: support smaller physical pages than PhysPageSize · f407ca92
      Austin Clements authored
      Most operations need an upper bound on the physical page size, which
      is what sys.PhysPageSize is for (this is checked at runtime init on
      Linux). However, a few operations need a *lower* bound on the physical
      page size. Introduce a "minPhysPageSize" constant to act as this lower
      bound and use it where it makes sense:
      
      1) In addrspace_free, we have to query each page in the given range.
         Currently we increment by the upper bound on the physical page
         size, which means we may skip over pages if the true size is
         smaller. Worse, we currently pass a result buffer that only has
         enough room for one page. If there are actually multiple pages in
         the range passed to mincore, the kernel will overflow this buffer.
         Fix these problems by incrementing by the lower-bound on the
         physical page size and by passing "1" for the length, which the
         kernel will round up to the true physical page size.
      
      2) In the write barrier, the bad pointer check tests for pointers to
         the first physical page, which are presumably small integers
         masquerading as pointers. However, if physical pages are smaller
         than we think, we may have legitimate pointers below
         sys.PhysPageSize. Hence, use minPhysPageSize for this test since
         pointers should never fall below that.
      
      In particular, this applies to ARM64 and MIPS. The runtime is
      configured to use 64kB pages on ARM64, but by default Linux uses 4kB
      pages. Similarly, the runtime assumes 16kB pages on MIPS, but both 4kB
      and 16kB kernel configurations are common. This also applies to ARM on
      systems where the runtime is recompiled to deal with a larger page
      size. It is also a step toward making the runtime use only a
      dynamically-queried page size.
      
      Change-Id: I1fdfd18f6e7cbca170cc100354b9faa22fde8a69
      Reviewed-on: https://go-review.googlesource.com/25020Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      Run-TryBot: Austin Clements <austin@google.com>
      f407ca92
    • Dmitry Vyukov's avatar
      runtime/race: fix memory leak · d73ca5f4
      Dmitry Vyukov authored
      The leak was reported internally on a sever canary that runs for days.
      After a day server consumes 5.6GB, after 6 days -- 12.2GB.
      The leak is exposed by the added benchmark.
      The leak is fixed upstream in :
      http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_rtl_thread.cc?view=diff&r1=276102&r2=276103&pathrev=276103
      
      Fixes #16441
      
      Change-Id: I9d4f0adef48ca6cf2cd781b9a6990ad4661ba49b
      Reviewed-on: https://go-review.googlesource.com/25091Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
      d73ca5f4
    • Ian Lance Taylor's avatar
      runtime: add as many extra M's as needed · 50048a4e
      Ian Lance Taylor authored
      When a non-Go thread calls into Go, the runtime needs an M to run the Go
      code. The runtime keeps a list of extra M's available. When the last
      extra M is allocated, the needextram field is set to tell it to allocate
      a new extra M as soon as it is running in Go. This ensures that an extra
      M will always be available for the next thread.
      
      However, if many threads need an extra M at the same time, this
      serializes them all. One thread will get an extra M with the needextram
      field set. All the other threads will see that there is no M available
      and will go to sleep. The one thread that succeeded will create a new
      extra M. One lucky thread will get it. All the other threads will see
      that there is no M available and will go to sleep. The effect is
      thundering herd, as all the threads looking for an extra M go through
      the process one by one. This seems to have a particularly bad effect on
      the FreeBSD scheduler for some reason.
      
      With this change, we track the number of threads waiting for an M, and
      create all of them as soon as one thread gets through. This still means
      that all the threads will fight for the lock to pick up the next M. But
      at least each thread that gets the lock will succeed, instead of going
      to sleep only to fight again.
      
      This smooths out the performance greatly on FreeBSD, reducing the
      average wall time of `testprogcgo CgoCallbackGC` by 74%.  On GNU/Linux
      the average wall time goes down by 9%.
      
      Fixes #13926
      Fixes #16396
      
      Change-Id: I6dc42a4156085a7ed4e5334c60b39db8f8ef8fea
      Reviewed-on: https://go-review.googlesource.com/25047
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      50048a4e
    • Brad Fitzpatrick's avatar
      net/smtp: document that the smtp package is frozen · 883e128f
      Brad Fitzpatrick authored
      This copies the frozen wording from the log/syslog package.
      
      Fixes #16436
      
      Change-Id: If5d478023328925299399f228d8aaf7fb117c1b4
      Reviewed-on: https://go-review.googlesource.com/25080Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      883e128f
  12. 18 Jul, 2016 1 commit