JDK-7147724 : G1: hang in SurrogateLockerThread::manipulatePLL
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-02-22
  • Updated: 2013-09-18
  • Resolved: 2012-03-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
JDK-7158682 - G1: Handle leak when running nsk.sysdict tests
Description
With HS23 b16 many tests hang in GC and VM is unresponsive. Here are interesting threads (full stack trace is attached):

Thread 13 (Thread 0xde7b9b70 (LWP 30484)):
#0  0xf77e4430 in __kernel_vsyscall ()
#1  0x4e9912fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xf701f4a1 in os::PlatformEvent::park (this=0xf6842700) at /tmp/jprt/P1/070954.jcoomes/source/src/os/linux/vm/os_linux.cpp:5036
#3  0xf6fe2f8a in Monitor::IWait (this=0xde3b3f40, Self=0xf6841400, timo=0) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/mutex.cpp:424
#4  0xf6fe3cca in Monitor::wait (this=0xde3b3f40, no_safepoint_check=1, timeout=0, as_suspend_equivalent=0) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/mutex.cpp:1111
#5  0xf6caada5 in SurrogateLockerThread::manipulatePLL (this=0xde3b3c00, msg=acquirePLL) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/gc_implementation/shared/concurrentGCThread.cpp:232
#6  0xf71ab763 in VM_CGC_Operation::doit_prologue (this=0xde7b92d4) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:174
#7  0xf71a81b4 in VMThread::execute (op=0xde7b92d4) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/vmThread.cpp:587
#8  0xf6ce59f9 in ConcurrentMarkThread::run (this=0xf6841400) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp:159
#9  0xf70237e1 in java_start (thread=0xf6841400) at /tmp/jprt/P1/070954.jcoomes/source/src/os/linux/vm/os_linux.cpp:886
#10 0x4e98d9e9 in start_thread () from /lib/libpthread.so.0
#11 0x4e8a3cde in clone () from /lib/libc.so.6

Thread 3 (Thread 0xddbffb70 (LWP 30508)):
#0  0xf77e4430 in __kernel_vsyscall ()
#1  0x4e994069 in __lll_lock_wait () from /lib/libpthread.so.0
#2  0x4e997331 in _L_cond_lock_726 () from /lib/libpthread.so.0
#3  0x4e997200 in __pthread_mutex_cond_lock () from /lib/libpthread.so.0
#4  0x4e9913ae in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#5  0xf701f4a1 in os::PlatformEvent::park (this=0xddc88f00) at /tmp/jprt/P1/070954.jcoomes/source/src/os/linux/vm/os_linux.cpp:5036
#6  0xf6fe2f8a in Monitor::IWait (this=0xf6806c30, Self=0xddc88000, timo=0) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/mutex.cpp:424
#7  0xf6fe41af in Monitor::wait (this=0xf6806c30, no_safepoint_check=0, timeout=0, as_suspend_equivalent=0) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/mutex.cpp:1126
#8  0xf71a8624 in VMThread::execute (op=0xddbfe590) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/vmThread.cpp:628
#9  0xf6d56617 in G1CollectedHeap::collect (this=0xf68137b0, cause=_g1_humongous_allocation) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:2440
#10 0xf6d637cd in G1CollectedHeap::attempt_allocation_humongous (this=0xf68137b0, word_size=268438, gc_count_before_ret=0xddbfea84) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:1036
#11 0xf6d63abb in G1CollectedHeap::mem_allocate (this=0xf68137b0, word_size=268438, gc_overhead_limit_was_exceeded=0xddbfeb0b) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:876
#12 0xf7146ad5 in typeArrayKlass::allocate_common (this=0xf03007a8, length=1073740, do_zero=1, __the_thread__=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/gc_interface/collectedHeap.inline.hpp:150
#13 0xf700c86f in oopFactory::new_typeArray (type=T_BYTE, length=1073740, __the_thread__=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/memory/oopFactory.cpp:80
#14 0xf6dfd467 in InterpreterRuntime::newarray (thread=0xddc88000, type=T_BYTE, size=1073740) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/interpreter/interpreterRuntime.cpp:188
#15 0xf4715885 in ?? ()
#16 0xf470352a in ?? ()
#17 0xf4703aa8 in ?? ()
#18 0xf4703397 in ?? ()
#19 0xf4703397 in ?? ()
#20 0xf4703915 in ?? ()
#21 0xf470043d in ?? ()
#22 0xf6e09b13 in JavaCalls::call_helper (result=0xddbfef58, m=0xddbfee74, args=0xddbfeebc, __the_thread__=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/javaCalls.cpp:415
#23 0xf701a719 in os::os_exception_wrapper (f=0xf6e09520 <JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)>, value=0xddbfef58, method=0xddbfee74, args=0xddbfeebc, thread=0xddc88000)
    at /tmp/jprt/P1/070954.jcoomes/source/src/os/linux/vm/os_linux.cpp:4484
#24 0xf6e08a37 in JavaCalls::call_virtual (result=0xddbfef58, spec_klass=..., name=0xf6892250, signature=0xf6896280, args=0xddbfeebc, __the_thread__=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/javaCalls.cpp:320
#25 0xf6e08c11 in JavaCalls::call_virtual (result=0xddbfef58, receiver=..., spec_klass=..., name=0xf6892250, signature=0xf6896280, __the_thread__=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/javaCalls.cpp:223
#26 0xf6e9362c in thread_entry (thread=0xddc88000, __the_thread__=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/prims/jvm.cpp:2630
#27 0xf7135ed9 in JavaThread::thread_main_inner (this=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/thread.cpp:1544
#28 0xf713656e in JavaThread::run (this=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/share/vm/runtime/thread.cpp:1524
#29 0xf70237e1 in java_start (thread=0xddc88000) at /tmp/jprt/P1/070954.jcoomes/source/src/os/linux/vm/os_linux.cpp:886
#30 0x4e98d9e9 in start_thread () from /lib/libpthread.so.0
#31 0x4e8a3cde in clone () from /lib/libc.so.6
Comments
Verified in PIT by Evdokim: in HS24-b07 for JDK7u6-b05
14-06-2013
EVALUATION http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/de5748cca211
28-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/64bf7c8270cb
21-03-2012
EVALUATION A couple of issues: When a thread that's attempting to allocate a humongous object determines that it should initiate a marking cycle, it can get into a busy retry-loop if the IM pause in not successful (the pause may not be successful for a variety od reasons). A thread that's attempting to allocate a humongous object can partipate in a deadlock situation: * The VM thread is trying to bring the VM to a safepoint and is waiting until the allocating thread blocks at a safepoint. * The allocating thread is not at a safepoint, but is trying to allocate a humongous object and is waiting on the CM thread resetting the _free_regions coming flag. * The CM thread is not particpating in safepoints (currently). It has just completed a cleanup pause and is blocked waiting in the cleanup operation's doit_epilogue() method until it has been told by the SLT that the PLL is no longer being held on it's behalf. The CM thread won't reset the _free_regions_coming flag until after clean operation (and concurrent cleanup operation) is complete. * The SLT is blocked for the safepoint operation, waiting until woken after the safepoint operation is complete.
01-03-2012