1. 07 Jan, 2020 1 commit
    • Dan Scales's avatar
      runtime: avoid potential deadlock when tracing memory code · f266cce6
      Dan Scales authored
      In reclaimChunk, the runtime is calling traceGCSweepDone() while holding the mheap
      lock. traceGCSweepDone() can call traceEvent() and traceFlush(). These functions
      not only can get various trace locks, but they may also do memory allocations
      (runtime.newobject) that may end up getting the mheap lock. So, there may be
      either a self-deadlock or a possible deadlock between multiple threads.
      
      It seems better to release the mheap lock before calling traceGCSweepDone(). It is
      fine to release the lock, since the operations to get the index of the chunk of
      work to do are atomic. We already release the lock to call sweep, so there is no
      new behavior for any of the callers of reclaimChunk.
      
      With this change, mheap is a leaf lock (no other lock is ever acquired while it
      is held).
      
      Testing: besides normal all.bash, also ran all.bash with --long enabled, since
      it does longer tests of runtime/trace.
      
      Change-Id: I4f8cb66c24bb8d424f24d6c2305b4b8387409248
      Reviewed-on: https://go-review.googlesource.com/c/go/+/207846Reviewed-by: default avatarAustin Clements <austin@google.com>
      Reviewed-by: default avatarMichael Knyszek <mknyszek@google.com>
      f266cce6
  2. 06 Jan, 2020 19 commits
  3. 04 Jan, 2020 4 commits
  4. 03 Jan, 2020 11 commits
  5. 02 Jan, 2020 5 commits