The fix for 6774607 was insufficient. Fix it correctly this time by using compressed pointers for linking up the overflown objects. The old fix in 6774607 was still vbulnerable in the case where the overflown  customer  was an  customer  array whose size is
larger than ParGCArrayScanChunk.
Posted Date : 2009-03-19 23:36:06.0

-XX:-UseParNewGC

OR

-XX:-UseCompressedOops

OR

-XX:ParGCArrayScanChunk=<LARGER THAN LARGEST OBJECT ARRAY EVER ALLOCATED BY PROGRAM>

Each of these three alternatives however can adversely (sometimes very adversely)
affect performance.
In particular, the last workaround above, of increasing the default value of
ParGCArrayScanChunk is a bit of a Catch-22, in the sense that increasing
the value can (if the user's program uses large arrays) actually
increase the incidence of work queue overflow (and thus adversely
affect performance). However, despite the overflow, the program will
continue to work properly in that case. On the other hand, with a small
value for the option, the chances of overflow are now much reduced
(even in the presence of very large object arrays in the heap); however,
were such an overflow to occur, involving an object array, then we would
be vulnerable to corrupting the heap and/or crashing in GC.

See suggested fix section.
Posted Date : 2009-03-19 23:40:30.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cea947c8a988
Posted Date : 2009-03-29 01:45:31.0