EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/master/rev/37689fc951e7
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/37689fc951e7
                                     

EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bda703475ded
                                     

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.
                                     

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.
                                     

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.