-
Bug
-
Resolution: Fixed
-
P4
-
hs25, 8u91, 9
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8083384 | emb-9 | Bengt Rutisson | P4 | Resolved | Fixed | b32 |
The mentioned test timed out during nightlies. pstack output indicates that the GC (G1) seems to be busy verifying the heap at VM exit.
I.e. the stack for the thread exiting:
fffffff7503052c8 __1cCosNPlatformEventEpark6M_v_ (100114900, 179000, 100114938, 100114950, fffffff750b2faa1, fffffff750e27860) + 140
fffffff7502731dc __1cHMonitorFIWait6MpnGThread_l_i_ (100b399b8, 103d63000, 0, b7018, 103d63000, 100114900) + d4
fffffff750274578 __1cHMonitorEwait6Mblb_b_ (100b399b8, 103d63000, 0, 0, fffffff750aec5bb, bb348c) + 1a8
fffffff75063b814 __1cIVMThreadXwait_for_vm_thread_exit6F_v_ (fffffff750f2d360, 156800, fffffff750f7e100, fffffff750e27860, fffffff750f7e0f9, 105b00) + 94
fffffff750565db0 __1cHThreadsKdestroy_vm6F_b_ (fffffff750efbee4, ffffffff7dcffd75, ffffffff7dcffd38, fffffff750e27860, 103d63000, 100111ab8) + 218
fffffff74fee5d78 jni_DestroyJavaVM (10c000, 123800, 103d63000, fffffff7509effff, fffffff750e27860, 0) + 2b0
and many other threads are busy verifying the heap, the stack trace looking something like
fffffff74fbe52d4 __1cSG1BlockOffsetArraybMforward_to_block_containing_addr_const6kMpnIHeapWord_2pkv_2_ (0, fffffffde0ea74f8, b6e01, fffffffde0eb0a00, 28, fffffffde0ea7520) + 1f4
fffffff74fbe3da8 __1cSG1BlockOffsetArrayRverify_for_object6kMpnIHeapWord_L_b_ (100d8e680, fffffffde0eb09e0, c, 0, 1707585, fffffff7508bfe80) + 150
fffffff74fcca91c __1cKHeapRegionGverify6kMnMVerifyOption_pb_v_ (100d8e608, 0, ffffffff7caff9bf, ffffffff2101fd70, fffffff750931840, fffffff750edefda) + 22c
fffffff74fc052e4 __1cTVerifyRegionClosureMdoHeapRegion6MpnKHeapRegion__b_ (ffffffff7caffb38, 100d8e608, 0, fffffff750ed2048, 0, 0) + 34
It may also be that the machine is just too loaded/slow.
ILW: H (hang?), L (only occurrence), M (workaround: do not do heap verification at end of gc)
I.e. the stack for the thread exiting:
fffffff7503052c8 __1cCosNPlatformEventEpark6M_v_ (100114900, 179000, 100114938, 100114950, fffffff750b2faa1, fffffff750e27860) + 140
fffffff7502731dc __1cHMonitorFIWait6MpnGThread_l_i_ (100b399b8, 103d63000, 0, b7018, 103d63000, 100114900) + d4
fffffff750274578 __1cHMonitorEwait6Mblb_b_ (100b399b8, 103d63000, 0, 0, fffffff750aec5bb, bb348c) + 1a8
fffffff75063b814 __1cIVMThreadXwait_for_vm_thread_exit6F_v_ (fffffff750f2d360, 156800, fffffff750f7e100, fffffff750e27860, fffffff750f7e0f9, 105b00) + 94
fffffff750565db0 __1cHThreadsKdestroy_vm6F_b_ (fffffff750efbee4, ffffffff7dcffd75, ffffffff7dcffd38, fffffff750e27860, 103d63000, 100111ab8) + 218
fffffff74fee5d78 jni_DestroyJavaVM (10c000, 123800, 103d63000, fffffff7509effff, fffffff750e27860, 0) + 2b0
and many other threads are busy verifying the heap, the stack trace looking something like
fffffff74fbe52d4 __1cSG1BlockOffsetArraybMforward_to_block_containing_addr_const6kMpnIHeapWord_2pkv_2_ (0, fffffffde0ea74f8, b6e01, fffffffde0eb0a00, 28, fffffffde0ea7520) + 1f4
fffffff74fbe3da8 __1cSG1BlockOffsetArrayRverify_for_object6kMpnIHeapWord_L_b_ (100d8e680, fffffffde0eb09e0, c, 0, 1707585, fffffff7508bfe80) + 150
fffffff74fcca91c __1cKHeapRegionGverify6kMnMVerifyOption_pb_v_ (100d8e608, 0, ffffffff7caff9bf, ffffffff2101fd70, fffffff750931840, fffffff750edefda) + 22c
fffffff74fc052e4 __1cTVerifyRegionClosureMdoHeapRegion6MpnKHeapRegion__b_ (ffffffff7caffb38, 100d8e608, 0, fffffff750ed2048, 0, 0) + 34
It may also be that the machine is just too loaded/slow.
ILW: H (hang?), L (only occurrence), M (workaround: do not do heap verification at end of gc)
- backported by
-
JDK-8083384 gc/memory/UniThread/Linear1 times out during heap verification
-
- Resolved
-
- duplicates
-
JDK-8028425 G1 verification code can be very slow
-
- Closed
-
- relates to
-
JDK-8019902 G1: Use the average heap size rather than the minimum heap size to calculate the region size
-
- Resolved
-
-
JDK-8055816 Remove dead code in g1BlockOffsetTable
-
- Resolved
-