runtime: avoid potential deadlock when tracing memory code
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: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Showing
Please register or sign in to comment