From 8bc6a58df7046b4d6f4b51eb274c7e60fea396ff Mon Sep 17 00:00:00 2001 From: Hans Boehm Date: Tue, 19 Dec 2023 18:48:15 +0000 Subject: 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 --- openjdkjvmti/ti_heap.cc | 7 ------- 1 file changed, 7 deletions(-) (limited to 'openjdkjvmti/ti_heap.cc') 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)); -- cgit v1.2.3-59-g8ed1b