Use r/w Mutex to control access to jvmtiEnv event information.
We were previously relying on the mutator_lock_ to provide
synchronization when accessing control information for some jvmti
events. This was not fully thread safe. To fix this problem we
instead use a ReaderWriterMutex to control access to this data.
Refactorings to allow all methods to have appropriate lock annotations
will follow in later CL (see bug).
Performance Impact:
Tested performance by running main piece of test 993 10 times.
Printing redirected to /dev/null.
Total of ~270 breakpoints are executed.
Before: 2.62 seconds / run
After: 2.72 seconds / run
Test: ./test.py --host -j50
Test: ./art/tools/run-prebuilt-libjdwp-tests.sh --debug
Bug: 62821960
Bug: 67958496
Bug: 67962439
Change-Id: Ib2935c2e10bc2113e8430b49a9a7b76144e4235e
diff --git a/openjdkjvmti/ti_stack.cc b/openjdkjvmti/ti_stack.cc
index e0c1399..23cf659 100644
--- a/openjdkjvmti/ti_stack.cc
+++ b/openjdkjvmti/ti_stack.cc
@@ -1024,9 +1024,12 @@
method,
visitor.GetDexPc());
}
- // Mark shadow frame as needs_notify_pop_
- shadow_frame->SetNotifyPop(true);
- tienv->notify_frames.insert(shadow_frame);
+ {
+ art::WriterMutexLock lk(self, tienv->event_info_mutex_);
+ // Mark shadow frame as needs_notify_pop_
+ shadow_frame->SetNotifyPop(true);
+ tienv->notify_frames.insert(shadow_frame);
+ }
// Make sure can we will go to the interpreter and use the shadow frames.
if (needs_instrument) {
art::Runtime::Current()->GetInstrumentation()->InstrumentThreadStack(target);