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,