ART: Fix lock order issue in allocation tracking

(Un)instrumenting requires the instrumenting lock, which must be
acquired before the mutator lock. As the plugin can be called both
with and without the lock held, be careful. For simplicity, acquire
the lock (potentially) and immediately suspend.

Bug: 31684277
Test: m test-art-host
Change-Id: Ia6cee2cbe90f13f5543bdfea815d469b28a0f8f4

diff --git a/runtime/openjdkjvmti/events.cc b/runtime/openjdkjvmti/events.cc
index 450f85e..9ff6c93 100644 (file)
--- a/runtime/openjdkjvmti/events.cc
+++ b/runtime/openjdkjvmti/events.cc
@@ -40,6 +40,8 @@
 #include "mirror/object.h"
 #include "runtime.h"
 #include "ScopedLocalRef.h"
+#include "scoped_thread_state_change-inl.h"
+#include "thread-inl.h"
 
 namespace openjdkjvmti {
 
@@ -172,6 +174,10 @@ class JvmtiAllocationListener : public art::gc::AllocationListener {
 };
 
 static void SetupObjectAllocationTracking(art::gc::AllocationListener* listener, bool enable) {
+  // We must not hold the mutator lock here, but if we're in FastJNI, for example, we might. For
+  // now, do a workaround: (possibly) acquire and release.
+  art::ScopedObjectAccess soa(art::Thread::Current());
+  art::ScopedThreadSuspension sts(soa.Self(), art::ThreadState::kSuspended);
   if (enable) {
     art::Runtime::Current()->GetHeap()->SetAllocationListener(listener);
   } else {