Reorder kThreadWaitLock
In aosp/814976, a new lock level was created for thread wait locks,
which were previously at kDefaultMutexLevel. I missed that another lock,
kMarkSweepMarkStackLock, was acquired while holding the thread wait
lock. This corrects the ordering.
Bug: 119755302
Change-Id: Ib55228d2759e281dc0f3a2177a538fd9adfec163
diff --git a/runtime/base/mutex.h b/runtime/base/mutex.h
index 0c8fe58..e391a15 100644
--- a/runtime/base/mutex.h
+++ b/runtime/base/mutex.h
@@ -73,13 +73,17 @@
// level lock, it is permitted to acquire a second one - with internal safeguards to ensure that
// the second lock acquisition does not result in deadlock. This is implemented in the lock
// order by treating the second acquisition of a kThreadWaitLock as a kThreadWaitWakeLock
- // acquisition. Thus, acquiring kThreadWaitWakeLock requires holding kThreadWaitLock.
+ // acquisition. Thus, acquiring kThreadWaitWakeLock requires holding kThreadWaitLock. This entry
+ // is here near the bottom of the hierarchy because other locks should not be
+ // acquired while it is held. kThreadWaitLock cannot be moved here because GC
+ // activity acquires locks while holding the wait lock.
kThreadWaitWakeLock,
- kThreadWaitLock,
kJdwpAdbStateLock,
kJdwpSocketLock,
kRegionSpaceRegionLock,
kMarkSweepMarkStackLock,
+ // Can be held while GC related work is done, and thus must be above kMarkSweepMarkStackLock
+ kThreadWaitLock,
kCHALock,
kJitCodeCacheLock,
kRosAllocGlobalLock,