JDK-8143546 : Test times out. VM appears to be blocked in GC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-11-20
  • Updated: 2015-11-23
  • Resolved: 2015-11-23
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 9
9Resolved
Related Reports
Duplicate :  
Description
 There are a lot of gc threads waiting here:

ffffffedc6fe34bc __1cYConcurrentG1RefineThreadbAwait_for_completed_buffers6M_v_ (10015c800, 15e0, ffffffedc8670498, 1400, 183c00, 1) + 74 
Comments
The clue to this hang is in the debuggee pstack log (pstack.core.14720): ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7eee6ad0 recv (6, ffffffff7dffeeb0, e, 0) ffffffff7d30db28 recv (6, ffff7fff, e, 0, ffff7c00, 0) + 1c fffffffcbe903750 dbgsysRecv (6, ffffffff7dffeeb0, e, 0, 0, 6) + 18 fffffffcbe902e14 recv_fully (6, ffffffff7dffeeb0, e, 6, e, 0) + 2c fffffffcbe901f6c handshake (fffffffcbe903f90, 0, 0, fffffffcbea042e0, 6, ffffffff7dffeeb0) + e4 fffffffcbe902a74 socketTransport_attach (0, 100122b0a, 0, 0, fffffffcbea04830, fffffffcbe9028f0) + 184 fffffffcba332a80 transport_startTransport (0, 100122b00, 100122b0a, 0, fffffffcba4440a8, fffffffcba442d40) + 2c0 fffffffcba31a1e0 startTransport (100122c10, ffffffff7dfff748, c00, fffffffcba443960, fffffffcba442d40, fffffffcba33cf50) + 60 fffffffcba316dc0 bagEnumerateOver (100122ba0, fffffffcba31a180, ffffffff7dfff748, 18, 800, 0) + 30 fffffffcba31a958 initialize (10012ba40, 100594488, fffffffcba33d160, ffffffedc759d260, fffffffcba442d40, 13) + 380 fffffffcba319a40 cbEarlyVMInit (c00, 10012ba40, 100594488, fffffffcba33ccb0, fffffffcba442d40, 1) + e8 ffffffedc763459c __1cLJvmtiExportTpost_vm_initialized6F_v_ (0, ffffffedc8729258, 10012b800, ffffffedc8670498, ffffffedc81c29e9, 1001221d0) + 6dc ffffffedc7bb6e48 __1cHThreadsJcreate_vm6FpnOJavaVMInitArgs_pb_i_ (10012b800, 0, 0, ffffffedc87054a1, 10012b800, ffffffedc8670498) + 870 ffffffedc745a9cc __1cWJNI_CreateJavaVM_inner6FppnHJavaVM__ppv3_i_ (ffffffff7dffff30, ffffffff7dffff28, ffffffff7dfffe58, 53d000, 1, ffffffedc8670498) + d4 ffffffedc880acec InitializeJVM (ffffffff7dffff30, ffffffff7dffff28, ffffffedc745ade0, 10000, 8, ffffffff7dfffe58) + f4 ffffffedc8809050 JavaMain (0, b10, 100106690, 100106ce0, ffffffedc8917770, 9) + 68 ffffffff7eee25b4 _lwp_start (0, 0, 0, 0, 0, 0) This stack looked familiar and after searching for "post_vm_initialized" test failures, I ran into this very old bug: JDK-6303969 JDWP: Socket Transport handshake fails rarely on InstancesTest.java https://bugs.openjdk.java.net/browse/JDK-6303969 I think this bug can be closed as a duplicate of JDK-6303969.
23-11-2015

That's normal that refinement threads are waiting on work to refinement. Also this is not the top-level stack entry, but the usual blocked on a mutex "fingerprint".
23-11-2015