1. 07 Apr, 2017 1 commit
  2. 05 Apr, 2017 21 commits
  3. 29 Mar, 2017 1 commit
    • Brad Fitzpatrick's avatar
      [release-branch.go1.8] net, net/http: adjust time-in-past constant even earlier · e35c01b4
      Brad Fitzpatrick authored
      The aLongTimeAgo time value in net and net/http is used to cancel
      in-flight read and writes. It was set to time.Unix(233431200, 0)
      which seemed like far enough in the past.
      
      But Raspberry Pis, lacking a real time clock, had to spoil the fun and
      boot in 1970 at the Unix epoch time, breaking assumptions in net and
      net/http.
      
      So change aLongTimeAgo to time.Unix(1, 0), which seems like the
      earliest safe value. I don't trust subsecond values on all operating
      systems, and I don't trust the Unix zero time. The Raspberry Pis do
      advance their clock at least. And the reported problem was that Hijack
      on a ResponseWriter hung forever, waiting for the connection read
      operation to finish. So now, even if kernel + userspace boots in under
      a second (unlikely), the Hijack will just have to wait for up to a
      second.
      
      Updates #19747
      Fixes #19771 (backport to Go 1.8.x)
      
      Change-Id: Id59430de2e7b5b5117d4903a788863e9d344e53a
      Reviewed-on: https://go-review.googlesource.com/38785
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      (cherry picked from commit e83fc2e44336423dab94bfe74fad4c4e6a4703b3)
      Reviewed-on: https://go-review.googlesource.com/38786Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      e35c01b4
  4. 27 Mar, 2017 1 commit
  5. 25 Mar, 2017 1 commit
  6. 23 Mar, 2017 1 commit
  7. 16 Mar, 2017 1 commit
  8. 09 Mar, 2017 1 commit
  9. 08 Mar, 2017 1 commit
  10. 03 Mar, 2017 3 commits
    • Cherry Zhang's avatar
      [release-branch.go1.8] cmd/compile: do not fold offset into load/store for args on ARM64 · 2327d696
      Cherry Zhang authored
      Args may be not at 8-byte aligned offset to SP. When the stack
      frame is large, folding the offset of args may cause large
      unaligned offsets that does not fit in a machine instruction on
      ARM64. Therefore disable folding offsets for args.
      
      This has small performance impact (see below). A better fix would
      be letting the assembler backend fix up the offset by loading it
      into a register if it doesn't fit into an instruction. And the
      compiler can simply generate large load/stores with offset. Since
      in most of the cases the offset is aligned or the stack frame is
      small, it can fit in an instruction and no fixup is needed. But
      this is too complicated for Go 1.8.
      
      name                     old time/op    new time/op    delta
      BinaryTree17-8              8.30s ± 0%     8.31s ± 0%    ~     (p=0.579 n=10+10)
      Fannkuch11-8                6.14s ± 0%     6.18s ± 0%  +0.53%  (p=0.000 n=9+10)
      FmtFprintfEmpty-8           117ns ± 0%     117ns ± 0%    ~     (all equal)
      FmtFprintfString-8          196ns ± 0%     197ns ± 0%  +0.72%  (p=0.000 n=10+10)
      FmtFprintfInt-8             204ns ± 0%     205ns ± 0%  +0.49%  (p=0.000 n=9+10)
      FmtFprintfIntInt-8          302ns ± 0%     307ns ± 1%  +1.46%  (p=0.000 n=10+10)
      FmtFprintfPrefixedInt-8     329ns ± 2%     326ns ± 0%    ~     (p=0.083 n=10+10)
      FmtFprintfFloat-8           540ns ± 0%     542ns ± 0%  +0.46%  (p=0.000 n=8+7)
      FmtManyArgs-8              1.20µs ± 1%    1.19µs ± 1%  -1.02%  (p=0.000 n=10+10)
      GobDecode-8                17.3ms ± 1%    17.8ms ± 0%  +2.75%  (p=0.000 n=10+7)
      GobEncode-8                15.3ms ± 1%    15.4ms ± 0%  +0.57%  (p=0.004 n=9+10)
      Gzip-8                      789ms ± 0%     803ms ± 0%  +1.78%  (p=0.000 n=9+10)
      Gunzip-8                    128ms ± 0%     130ms ± 0%  +1.73%  (p=0.000 n=10+9)
      HTTPClientServer-8          202µs ± 6%     201µs ±10%    ~     (p=0.739 n=10+10)
      JSONEncode-8               42.0ms ± 0%    42.1ms ± 0%  +0.19%  (p=0.028 n=10+9)
      JSONDecode-8                159ms ± 0%     161ms ± 0%  +1.05%  (p=0.000 n=9+10)
      Mandelbrot200-8            10.1ms ± 0%    10.1ms ± 0%  -0.07%  (p=0.000 n=10+9)
      GoParse-8                  8.46ms ± 1%    8.61ms ± 1%  +1.77%  (p=0.000 n=10+10)
      RegexpMatchEasy0_32-8       227ns ± 1%     226ns ± 0%  -0.35%  (p=0.001 n=10+9)
      RegexpMatchEasy0_1K-8      1.63µs ± 0%    1.63µs ± 0%  -0.13%  (p=0.000 n=10+9)
      RegexpMatchEasy1_32-8       250ns ± 0%     249ns ± 0%  -0.40%  (p=0.001 n=8+9)
      RegexpMatchEasy1_1K-8      2.07µs ± 0%    2.08µs ± 0%  +0.05%  (p=0.027 n=9+9)
      RegexpMatchMedium_32-8      350ns ± 0%     350ns ± 0%    ~     (p=0.412 n=9+8)
      RegexpMatchMedium_1K-8      104µs ± 0%     104µs ± 0%  +0.31%  (p=0.000 n=10+7)
      RegexpMatchHard_32-8       5.82µs ± 0%    5.82µs ± 0%    ~     (p=0.937 n=9+9)
      RegexpMatchHard_1K-8        176µs ± 0%     176µs ± 0%  +0.03%  (p=0.000 n=9+8)
      Revcomp-8                   1.36s ± 1%     1.37s ± 1%    ~     (p=0.218 n=10+10)
      Template-8                  151ms ± 1%     156ms ± 1%  +3.21%  (p=0.000 n=10+10)
      TimeParse-8                 737ns ± 0%     758ns ± 2%  +2.74%  (p=0.000 n=10+10)
      TimeFormat-8                801ns ± 2%     789ns ± 1%  -1.51%  (p=0.000 n=10+10)
      [Geo mean]                  142µs          143µs       +0.50%
      
      Fixes #19137.
      
      Change-Id: Ib8a21ea98c0ffb2d282a586535b213cc163e1b67
      Reviewed-on: https://go-review.googlesource.com/37251
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      (cherry picked from commit 6464e5dc)
      Reviewed-on: https://go-review.googlesource.com/37719Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      2327d696
    • Cherry Zhang's avatar
      [release-branch.go1.8] cmd/compile: check both syms when folding address into load/store on ARM64 · ba48d200
      Cherry Zhang authored
      The rules for folding addresses into load/stores checks sym1 is
      not on stack (because the stack offset is not known at that point).
      But sym1 could be nil, which invalidates the check. Check merged
      sym instead.
      
      Fixes #19137.
      
      Change-Id: I8574da22ced1216bb5850403d8f08ec60a8d1005
      Reviewed-on: https://go-review.googlesource.com/37145
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      (cherry picked from commit 3557d546)
      Reviewed-on: https://go-review.googlesource.com/37214
      ba48d200
    • Cherry Zhang's avatar
      [release-branch.go1.8] cmd/compile: add zero-extension before right shift when lowering Lrot on ARM · b43fabfb
      Cherry Zhang authored
      Fixes #19270.
      
      Change-Id: Ie7538ff8465138a8bc02572e84cf5d00de7bbdd1
      Reviewed-on: https://go-review.googlesource.com/37718
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      b43fabfb
  11. 02 Mar, 2017 2 commits
  12. 27 Feb, 2017 1 commit
  13. 23 Feb, 2017 2 commits
  14. 16 Feb, 2017 3 commits
    • Chris Broadfoot's avatar
      [release-branch.go1.8] go1.8 · cd6b6202
      Chris Broadfoot authored
      Change-Id: If1e38f02db86449abd4c8a57988d9825b1cf2511
      Reviewed-on: https://go-review.googlesource.com/37132
      Run-TryBot: Chris Broadfoot <cbro@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      cd6b6202
    • Chris Broadfoot's avatar
      [release-branch.go1.8] doc: document go1.8 · 606eb9b0
      Chris Broadfoot authored
      Change-Id: Ie2144d001c6b4b2293d07b2acf62d7e3cd0b46a7
      Reviewed-on: https://go-review.googlesource.com/37130Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Reviewed-on: https://go-review.googlesource.com/37131
      606eb9b0
    • Russ Cox's avatar
      [release-branch.go1.8] runtime: do not call wakep from enlistWorker, to avoid possible deadlock · bcda91c1
      Russ Cox authored
      We have seen one instance of a production job suddenly spinning to
      100% CPU and becoming unresponsive. In that one instance, a SIGQUIT
      was sent after 328 minutes of spinning, and the stacks showed a single
      goroutine in "IO wait (scan)" state.
      
      Looking for things that might get stuck if a goroutine got stuck in
      scanning a stack, we found that injectglist does:
      
      	lock(&sched.lock)
      	var n int
      	for n = 0; glist != nil; n++ {
      		gp := glist
      		glist = gp.schedlink.ptr()
      		casgstatus(gp, _Gwaiting, _Grunnable)
      		globrunqput(gp)
      	}
      	unlock(&sched.lock)
      
      and that casgstatus spins on gp.atomicstatus until the _Gscan bit goes
      away. Essentially, this code locks sched.lock and then while holding
      sched.lock, waits to lock gp.atomicstatus.
      
      The code that is doing the scan is:
      
      	if castogscanstatus(gp, s, s|_Gscan) {
      		if !gp.gcscandone {
      			scanstack(gp, gcw)
      			gp.gcscandone = true
      		}
      		restartg(gp)
      		break loop
      	}
      
      More analysis showed that scanstack can, in a rare case, end up
      calling back into code that acquires sched.lock. For example:
      
      	runtime.scanstack at proc.go:866
      	calls runtime.gentraceback at mgcmark.go:842
      	calls runtime.scanstack$1 at traceback.go:378
      	calls runtime.scanframeworker at mgcmark.go:819
      	calls runtime.scanblock at mgcmark.go:904
      	calls runtime.greyobject at mgcmark.go:1221
      	calls (*runtime.gcWork).put at mgcmark.go:1412
      	calls (*runtime.gcControllerState).enlistWorker at mgcwork.go:127
      	calls runtime.wakep at mgc.go:632
      	calls runtime.startm at proc.go:1779
      	acquires runtime.sched.lock at proc.go:1675
      
      This path was found with an automated deadlock-detecting tool.
      There are many such paths but they all go through enlistWorker -> wakep.
      
      The evidence strongly suggests that one of these paths is what caused
      the deadlock we observed. We're running those jobs with
      GOTRACEBACK=crash now to try to get more information if it happens
      again.
      
      Further refinement and analysis shows that if we drop the wakep call
      from enlistWorker, the remaining few deadlock cycles found by the tool
      are all false positives caused by not understanding the effect of calls
      to func variables.
      
      The enlistWorker -> wakep call was intended only as a performance
      optimization, it rarely executes, and if it does execute at just the
      wrong time it can (and plausibly did) cause the deadlock we saw.
      
      Comment it out, to avoid the potential deadlock.
      
      Fixes #19112.
      Unfixes #14179.
      
      Change-Id: I6f7e10b890b991c11e79fab7aeefaf70b5d5a07b
      Reviewed-on: https://go-review.googlesource.com/37093
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      Reviewed-on: https://go-review.googlesource.com/37022
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      bcda91c1