From f1c6f8742e2ac980c7259f4dc70b4326ecc245e1 Mon Sep 17 00:00:00 2001 From: Hiroshi Yamauchi Date: Fri, 6 Jan 2017 12:23:47 -0800 Subject: Don't need to block in AddWeakGlobalRef and MonitorList::Add under CC. CMS needs this to block because an object allocated during the GC won't be marked and concurrent reference processing would incorrectly clear the JNI weak ref or the monitor list weak. But CC doesn't because of the to-space invariant, that is, when a mutator tries to create a JNI weak ref or a monitor for an object, it must be already marked and the concurrent reference processing wouldn't incorrectly clear it. Bug: 34128900 Bug: 12687968 Test: test-art-host with CC. Change-Id: Ia87bf8ed9e604900df5ecb450c89b0ac222bef32 --- runtime/java_vm_ext.cc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'runtime/java_vm_ext.cc') diff --git a/runtime/java_vm_ext.cc b/runtime/java_vm_ext.cc index f80c43d80c..e0f28adc4f 100644 --- a/runtime/java_vm_ext.cc +++ b/runtime/java_vm_ext.cc @@ -566,7 +566,10 @@ jweak JavaVMExt::AddWeakGlobalRef(Thread* self, ObjPtr obj) { return nullptr; } MutexLock mu(self, *Locks::jni_weak_globals_lock_); - while (UNLIKELY(!MayAccessWeakGlobals(self))) { + // CMS needs this to block for concurrent reference processing because an object allocated during + // the GC won't be marked and concurrent reference processing would incorrectly clear the JNI weak + // ref. But CC (kUseReadBarrier == true) doesn't because of the to-space invariant. + while (!kUseReadBarrier && UNLIKELY(!MayAccessWeakGlobals(self))) { // Check and run the empty checkpoint before blocking so the empty checkpoint will work in the // presence of threads blocking for weak ref access. self->CheckEmptyCheckpoint(); -- cgit v1.2.3-59-g8ed1b