archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-08-27 06:45:07 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

7147724: G1: hang in SurrogateLockerThread::manipulatePLL

Browse source 
Attempting to initiate a marking cycle when allocating a humongous object can, if a marking cycle is successfully initiated by another thread, result in the allocating thread spinning until the marking cycle is complete. Eliminate a deadlock between the main ConcurrentMarkThread, the SurrogateLocker thread, the VM thread, and a mutator thread waiting on the SecondaryFreeList_lock (while free regions are going to become available) by not manipulating the pending list lock during the prologue and epilogue of the cleanup pause.

Reviewed-by: brutisso, jcoomes, tonyp
This commit is contained in:
John Cuthbertson 2012-03-12 14:59:00 -07:00
parent 8950ee8d8e
commit 006def0451
4 changed files with 74 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

4
hotspot/src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
View file

@ -155,7 +155,7 @@ void ConcurrentMarkThread::run() {
CMCheckpointRootsFinalClosure final_cl(_cm);
sprintf(verbose_str, "GC remark");
VM_CGC_Operation op(&final_cl, verbose_str);
VM_CGC_Operation op(&final_cl, verbose_str, true /* needs_pll */);
VMThread::execute(&op);
}
if (cm()->restart_for_overflow() &&
@ -189,7 +189,7 @@ void ConcurrentMarkThread::run() {
CMCleanUp cl_cl(_cm);
sprintf(verbose_str, "GC cleanup");
VM_CGC_Operation op(&cl_cl, verbose_str);
VM_CGC_Operation op(&cl_cl, verbose_str, false /* needs_pll */);
VMThread::execute(&op);
} else {
// We don't want to update the marking status if a GC pause