1. 28 Oct, 2019 18 commits
  2. 27 Oct, 2019 3 commits
  3. 26 Oct, 2019 16 commits
  4. 25 Oct, 2019 3 commits
    • Austin Clements's avatar
      runtime: abstract M preemption check into a function · d1969015
      Austin Clements authored
      We check whether an M is preemptible in a surprising number of places.
      Put it in one function.
      
      For #10958, #24543.
      
      Change-Id: I305090fdb1ea7f7a55ffe25851c1e35012d0d06c
      Reviewed-on: https://go-review.googlesource.com/c/go/+/201439
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      d1969015
    • Austin Clements's avatar
      runtime: only shrink stacks at synchronous safe points · 60586034
      Austin Clements authored
      We're about to introduce asynchronous safe points, where we won't have
      precise pointer maps for all stack frames. That's okay for scanning
      the stack (conservatively), but not for shrinking the stack.
      
      Hence, this CL prepares for this by only shrinking the stack as part
      of the stack scan if the goroutine is stopped at a synchronous safe
      point. Otherwise, it queues up the stack shrink for the next
      synchronous safe point.
      
      We already have one condition under which we can't shrink the stack
      for very similar reasons: syscalls. Currently, we just give up on
      shrinking the stack if it's in a syscall. But with this mechanism, we
      defer that stack shrink until the next synchronous safe point.
      
      For #10958, #24543.
      
      Change-Id: Ifa1dec6f33fdf30f9067be2ce3f7ab8a7f62ce38
      Reviewed-on: https://go-review.googlesource.com/c/go/+/201438
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      60586034
    • Austin Clements's avatar
      runtime: make copystack/sudog synchronization more explicit · 36a432f2
      Austin Clements authored
      When we copy a stack of a goroutine blocked in a channel operation, we
      have to be very careful because other goroutines may be writing to
      that goroutine's stack. To handle this, stack copying acquires the
      locks for the channels a goroutine is waiting on.
      
      One complication is that stack growth may happen while a goroutine
      holds these locks, in which case stack copying must *not* acquire
      these locks because that would self-deadlock.
      
      Currently, stack growth never acquires these locks because stack
      growth only happens when a goroutine is running, which means it's
      either not blocking on a channel or it's holding the channel locks
      already. Stack shrinking always acquires these locks because shrinking
      happens asynchronously, so the goroutine is never running, so there
      are either no locks or they've been released by the goroutine.
      
      However, we're about to change when stack shrinking can happen, which
      is going to break the current rules. Rather than find a new way to
      derive whether to acquire these locks or not, this CL simply adds a
      flag to the g struct that indicates that stack copying should acquire
      channel locks. This flag is set while the goroutine is blocked on a
      channel op.
      
      For #10958, #24543.
      
      Change-Id: Ia2ac8831b1bfda98d39bb30285e144c4f7eaf9ab
      Reviewed-on: https://go-review.googlesource.com/c/go/+/172982
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMichael Knyszek <mknyszek@google.com>
      36a432f2