summaryrefslogtreecommitdiff
path: root/runtime/jit/jit_code_cache.cc
diff options
context:
space:
mode:
author Alex Light <allight@google.com> 2018-07-18 15:39:16 +0000
committer Alex Light <allight@google.com> 2018-07-18 16:10:50 -0700
commitd7da3147fea647ade418337aed6a8f9402412611 (patch)
tree74907194b84807ae327ba9aff876e1f9d4bbf7a4 /runtime/jit/jit_code_cache.cc
parenteee2ee8e17aa65656e9946c5beb4a0a49fee7509 (diff)
Revert^4 "Rewrite JVMTI method tracing to use trampolines"
Since we are unable to change the semantics of ClassLoaded and ClassPrepared due to b/111394423 for the moment changes were made in libjdwp to remove the deadlock between the jit being stopped and jit-threads trying to lock JVMTI monitors in libjdwp. Until some resolution for b/111394423 is implemented agents should be very careful about gaining locks in the ClassLoaded, ClassPrepared or VMObjectAlloc events if said lock is held over a call to SetEventNotificationMode, SetExtensionEventCallback, RetransformClasses, or RedefineClasses. These locks can only be safely held if the object argument to the event is not an array-class object or the thread is known not to be a jit thread. This reverts commit bf2ca05ccf658a9f626d1cb3f1adca6087ece7b8. Bug: 111394423 Test: ./art/tools/run-libjdwp-tests.sh --mode=host --debug Reason for revert: Fixed issue with libjdwp deadlocking on jit threads Change-Id: I8baeb8311f67062cbc26286eb221da34e1972f27
Diffstat (limited to 'runtime/jit/jit_code_cache.cc')
-rw-r--r--runtime/jit/jit_code_cache.cc15
1 files changed, 15 insertions, 0 deletions
diff --git a/runtime/jit/jit_code_cache.cc b/runtime/jit/jit_code_cache.cc
index eeb35156b5..70a717154b 100644
--- a/runtime/jit/jit_code_cache.cc
+++ b/runtime/jit/jit_code_cache.cc
@@ -362,6 +362,21 @@ const void* JitCodeCache::GetJniStubCode(ArtMethod* method) {
return nullptr;
}
+void JitCodeCache::ClearAllCompiledDexCode() {
+ MutexLock mu(Thread::Current(), lock_);
+ // Get rid of OSR code waiting to be put on a thread.
+ osr_code_map_.clear();
+
+ // We don't clear out or even touch method_code_map_ since that is what we use to go the other
+ // way, move from code currently-running to the method it's from. Getting rid of it would break
+ // the jit-gc, stack-walking and signal handling. Since we never look through it to go the other
+ // way (from method -> code) everything is fine.
+
+ for (ProfilingInfo* p : profiling_infos_) {
+ p->SetSavedEntryPoint(nullptr);
+ }
+}
+
const void* JitCodeCache::FindCompiledCodeForInstrumentation(ArtMethod* method) {
// If jit-gc is still on we use the SavedEntryPoint field for doing that and so cannot use it to
// find the instrumentation entrypoint.