Prevent concurrent GC stack-walks during deoptimization

We could end up modifying the instrumentation stack at the same time
the GC or thread-flip stack walks are occurring. This could cause
crashes or check-failures as the stack is in an inconsistent state.

To fix this we changed the deoptimization process to block GC stack
walks.

We also standardized openjdkjvmti.so deoptimization to use a single
entrypoint.

Bug: 72608560
Test: ./test.py --host
Test: ./tools/parallel_run.py

Change-Id: I942ff891930d22a579345265897916cf84842a1c

1 files changed, 7 insertions, 0 deletions

diff --git a/openjdkjvmti/deopt_manager.cc b/openjdkjvmti/deopt_manager.cc
index ec29f2cdda..a7feba81e1 100644
--- a/openjdkjvmti/deopt_manager.cc
+++ b/openjdkjvmti/deopt_manager.cc
@@ -42,6 +42,7 @@
 #include "dex/dex_file_annotations.h"
 #include "dex/modifiers.h"
 #include "events-inl.h"
+#include "gc/collector_type.h"
 #include "gc/heap.h"
 #include "gc/scoped_gc_critical_section.h"
 #include "jit/jit.h"
@@ -49,6 +50,7 @@
 #include "mirror/class-inl.h"
 #include "mirror/object_array-inl.h"
 #include "nativehelper/scoped_local_ref.h"
+#include "read_barrier_config.h"
 #include "runtime_callbacks.h"
 #include "scoped_thread_state_change-inl.h"
 #include "scoped_thread_state_change.h"
@@ -478,6 +480,11 @@ void DeoptManager::AddDeoptimizationRequester() {
 }
 
 void DeoptManager::DeoptimizeThread(art::Thread* target) {
+  // We might or might not be running on the target thread (self) so get Thread::Current
+  // directly.
+  art::gc::ScopedGCCriticalSection sgccs(art::Thread::Current(),
+                                         art::gc::GcCause::kGcCauseDebugger,
+                                         art::gc::CollectorType::kCollectorTypeDebugger);
   art::Runtime::Current()->GetInstrumentation()->InstrumentThreadStack(target);
 }