Here's a description from the Evaluation field of 6578335 during the
investigation of which this bug was first diagnosed:

There was a second bug in the overflow handling encountered during
the precleaning of reference lists. Because the same closure was used
for this work during the remark and during the preclean stage, we ended
up with incorrect overflow handling (correct for the remark phase,
incorrect for preclean phase). This needs to be fixed. The temporary
workaround is to disable CMSPrecleanRefLists{1,2}.
Posted Date : 2008-07-03 00:35:12.0

-XX:-CMSPrecleanRefLists{1,2}

This is a bug since 6.0 when precleaning of Reference lists was
first introduced. RE should check if the feature may have been
backported to earlier releases (unlikely) in which case other
subCR's may also need to be filed.
Posted Date : 2008-07-03 00:35:12.0

I checked, and this code is present at least in the latest 5uXX train as well,
but not in 1.4.2_XX. So we will need to fix this in 5uXX as well. I will file
a subCR for 5uXX once we have this fixed in hs14.
Posted Date : 2008-08-16 00:05:22.0

6722113 CMS: Incorrect overflow handling during precleaning of Reference lists

     http://bugs.sun.com/view_bug.do?bug_id=6722113

     webrev: http://webrev.invokedynamic.info/ysr/6722113/


One problem was that we had reused a CMS reference processing closure
to do concurrent precleaning of the discovered reference list,
but had not extended it to deal correctly with marking stack overflow
that might occur during a concurrent phase. The fix is to do so
in the usual way for CMS, by redirtying the MUT-card containing the
overflown object, taking care to deal with reference array objects
appropriately.

A further problem was that the marking done during the precleaning
pass was not updating the discovered list lengths correctly because
of the interleaved manner in which discovery and preclean-processing
proceed in this case. This could lead to issues during the rebalancing
of the per-thread discovered lists when doing reference processing
multi-threaded. Adjusted related comments. (Note that this is
the first case where we are explicitly doing reference processing
without disabling discovery,  I'd like to call this out explicitly
for reviewers to pay special attention to. This will require looking
at the reference processing code in detail, not just the portions
that changed in the webrev. Note that this will need to change
if concurrent precleaning were ever to become parallel/multi-threaded.)

Testing: jprt, refworkload, with and without +ParallelRefProcEnabled

Thanks for your reviews.
-- ramki
Posted Date : 2008-11-14 20:07:13.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/00b023ae2d78
Posted Date : 2008-11-20 23:25:03.0