Do not handle suspension request in StartGC

Switching back to kRunnable state while appearing to be running a
collection can lead to deadlock. Don't do that.

Unfortunately, StartGC is one of several functions in this area that
can be called with or without the mutator lock, complicating matters.

We implement this by adding a ThreadState value, so we don't need two
clones of TransitionFromRunnableToSuspended. This required trivial
updates to various unrelated switch statements to handle the new case.

Add some checking for kSuspensionImmune abuses. (An earlier attempt
tried to use that here.)

Bug: 304929145
Test: Treehugger
Change-Id: Id5e16fef3255ff243c4e7e306762ababd8cf2f70

1 files changed, 1 insertions, 0 deletions

diff --git a/runtime/native/java_lang_Thread.cc b/runtime/native/java_lang_Thread.cc
index 65e3009c0f..2c79a38ca0 100644
--- a/runtime/native/java_lang_Thread.cc
+++ b/runtime/native/java_lang_Thread.cc
@@ -108,6 +108,7 @@ static jint Thread_nativeGetStatus(JNIEnv* env, jobject java_thread, jboolean ha
     case ThreadState::kWaitingForGcThreadFlip:         return kJavaWaiting;
     case ThreadState::kNativeForAbort:                 return kJavaWaiting;
     case ThreadState::kSuspended:                      return kJavaRunnable;
+    case ThreadState::kInvalidState:                   break;
     // Don't add a 'default' here so the compiler can spot incompatible enum changes.
   }
   LOG(ERROR) << "Unexpected thread state: " << internal_thread_state;