JDK-6940894 : G1: assert(new_obj != 0 || ... "should be forwarded") for compaction tests
Type:Bug
Component:hotspot
Sub-Component:gc
Affected Version:hs17
Priority:P2
Status:Closed
Resolution:Fixed
OS:generic
CPU:x86
Submitted:2010-04-05
Updated:2013-09-18
Resolved:2011-03-08
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.
SUGGESTED FIX
If a region, retained from being to-space in a previous evacuation pause, is tagged as humongous then do not use it as to-space in the current evacuation pause.
05-04-2010
EVALUATION
It has been confirmed that a region that has been tagged as humongous is used as to-space during an evacuation pause causing objects to be placed after the humongous object at the base of the humongous region:
HS 0 space 1024K, 76% used [0xffffffff64c00000, 0xffffffff64cc49c8, 0xffffffff64d00000)
HS 0 space 1024K, 51% used [0xffffffff64d00000, 0xffffffff64d83138, 0xffffffff64e00000)
HS 0 space 1024K, 76% used [0xffffffff64e00000, 0xffffffff64ec49c8, 0xffffffff64f00000)
Y 0 space 1024K, 78% used [0xffffffff64f00000, 0xffffffff64fc8fe8, 0xffffffff65000000)
HS 0 space 1024K, 76% used [0xffffffff65000000, 0xffffffff650c49c8, 0xffffffff65100000)
HS 0 space 1024K, 76% used [0xffffffff65100000, 0xffffffff651c49c8, 0xffffffff65200000)
HS 0 space 1024K, 76% used [0xffffffff65200000, 0xffffffff652c49c8, 0xffffffff65300000)
Y 0 space 1024K, 78% used [0xffffffff65300000, 0xffffffff653c8fe8, 0xffffffff65400000)
HS 0 space 1024K, 76% used [0xffffffff65400000, 0xffffffff654c49c8, 0xffffffff65500000)
Y 0 space 1024K, 81% used [0xffffffff65500000, 0xffffffff655d1b98, 0xffffffff65600000)
[GC pause (young)Adding 4 young regions to the CSet
added region to cset 97:[0xffffffff65500000, 0xffffffff65600000], top 0xffffffff655d1b98, young YES
Added [0xffffffff65500000, 0xffffffff65600000) to CS.
(160953 KB left in heap.)
added region to cset 95:[0xffffffff65300000, 0xffffffff65400000], top 0xffffffff653c8fe8, young YES
Added [0xffffffff65300000, 0xffffffff65400000) to CS.
(160149 KB left in heap.)
added region to cset 91:[0xffffffff64f00000, 0xffffffff65000000], top 0xffffffff64fc8fe8, young YES
Added [0xffffffff64f00000, 0xffffffff65000000) to CS.
(159345 KB left in heap.)
added region to cset 55:[0xffffffff62b00000, 0xffffffff62c00000], top 0xffffffff62bb3e48, young YES
Added [0xffffffff62b00000, 0xffffffff62c00000) to CS.
(158625 KB left in heap.)
Setting GC alloc region with humongous region...
HS 0 space 1024K, 76% used [0xffffffff64c00000, 0xffffffff64cc49c8, 0xffffffff64d00000)
The region was allocated as to-space (but not tagged as humongous) during a previous evacuation pause, and retained as a gc alloc region. Between the two evacuation pauses, a marking cyle completed causing the region to be freed, subsequently allocated and tagged as humongous. Thus in the subsequent evacuation pause the region is seen as humongous.
The fix should be straight-forward.
05-04-2010
EVALUATION
This looks as if it has the same symptoms as 6755988: G1: assert(new_obj = 0 or ... "should be forwarded"). After talking with John Cuthbertson it looks as if the reason is different: we accidentally use a humongous region as to-space and copy objects into it during an evacuation pause.