Revert^17 "Thread suspension cleanup and deadlock fix"

This reverts commit c6371b52df0da31acc174a3526274417b7aac0a7.

Reason for revert: This seems to have two remaining issues:

1. The second DCHECK in WaitForFlipFunction is not completely guaranteed to hold, resulting in failures for 658-fp-read-barrier.
2. WaitForSuspendBarrier seems to time out occasionally, possibly spuriously so. We fail when the futex times out once. That's probably incompatible with the app freezer. We should retry a few times.

Change-Id: Ibd8909b31083fc29e6d4f1fcde003d08eb16fc0a

1 files changed, 0 insertions, 7 deletions

diff --git a/openjdkjvmti/ti_heap.cc b/openjdkjvmti/ti_heap.cc
index 80bfa0ff43..662f464ad2 100644
--- a/openjdkjvmti/ti_heap.cc
+++ b/openjdkjvmti/ti_heap.cc
@@ -975,13 +975,6 @@ class FollowReferencesHelper final {
     jvmtiHeapReferenceKind GetReferenceKind(const art::RootInfo& info,
                                             jvmtiHeapReferenceInfo* ref_info)
         REQUIRES_SHARED(art::Locks::mutator_lock_) {
-      // We do not necessarily hold thread_list_lock_ here, but we may if we are called from
-      // VisitThreadRoots, which can happen from JVMTI FollowReferences. If it was acquired in
-      // ThreadList::VisitRoots, it's unsafe to temporarily release it. Thus we act as if we did
-      // not hold the thread_list_lock_ here, and relax CHECKs appropriately. If it does happen,
-      // we are in a SuspendAll situation with concurrent GC disabled, and should not need to run
-      // flip functions. TODO: Find a way to clean this up.
-
       // TODO: Fill in ref_info.
       memset(ref_info, 0, sizeof(jvmtiHeapReferenceInfo));