Fix issue with RawMonitors around thread suspension.

Investigation of real-world JVMTI agents revealed that some rely on
the RawMonitorEnter function acting as a Java suspend point. If it
fails to act as one the agent could end up deadlocked.

Test: ./test.py --host -j50
Bug: 62821960
Bug: 34415266

Change-Id: I3daf5c49c1c9870e1f69eebfd4c6f2ad15224510

1 files changed, 16 insertions, 0 deletions

diff --git a/openjdkjvmti/ti_thread.h b/openjdkjvmti/ti_thread.h
index a19974aa16..57b194362f 100644
--- a/openjdkjvmti/ti_thread.h
+++ b/openjdkjvmti/ti_thread.h
@@ -98,6 +98,22 @@ class ThreadUtil {
       REQUIRES_SHARED(art::Locks::mutator_lock_)
       REQUIRES(art::Locks::thread_list_lock_);
 
+  // Go to sleep if this thread is suspended.
+  static void SuspendCheck(art::Thread* self)
+    REQUIRES(!art::Locks::mutator_lock_, !art::Locks::user_code_suspension_lock_);
+
+  // Returns true if the thread would be suspended if it locks the mutator-lock or calls
+  // SuspendCheck. This function is called with the user_code_suspension_lock already held.
+  static bool WouldSuspendForUserCodeLocked(art::Thread* self)
+    REQUIRES(art::Locks::user_code_suspension_lock_,
+             !art::Locks::thread_suspend_count_lock_);
+
+  // Returns true if this thread would go to sleep if it locks the mutator-lock or calls
+  // SuspendCheck.
+  static bool WouldSuspendForUserCode(art::Thread* self)
+    REQUIRES(!art::Locks::user_code_suspension_lock_,
+             !art::Locks::thread_suspend_count_lock_);
+
  private:
   // We need to make sure only one thread tries to suspend threads at a time so we can get the
   // 'suspend-only-once' behavior the spec requires. Internally, ART considers suspension to be a