Request for review (S): 6668573: CMS: reference processing crash if ParallelCMSThreads > ParallelGCThreads
Y. Srinivas Ramakrishna
y.s.ramakrishna at oracle.com
Mon Mar 14 16:43:39 PDT 2011
Note on "(S)" above: although there are a number of
files that are touched, the changes are simple and
are similar in shape across the collectors.
Problem: The assumption that ConcGCThreads <= ParallelGCThreads had
been hardwired into some of the code in the reference processor:
the concept of an mt-discovery degree that could be distinct from
mt-processing degree was also not clearly articulated in some
portions of the code. A final problem was a bug in CMS+ParallelRefProcEnabled
that had sneaked in undetected late last year and not known until
late last week.
Solution: In the reference processor class, allow
for the possibility that mt-discovery degree is distinct from,
and possibly larger than, mt-processing degree
(when specific collectors choose to allow it).
The remainder of the work is then taken care of
by previous work in balance_queues().
Fix the CMS+ParallelRefProcEnabled regression
by means of explicitly setting the terminator
object in the parallel reference processing task
Testing: various combinations of
collector, parallel gc threads, concurrent gc threads
and parallel reference processing settings.
-XX:Use<...>GC -XX:ParallelGCThreads=... -XX:ConcGCThreads=... -XX:+/-ParallelRefProcEnabled
Thanks to Jon Masamitsu and John Cuthbertson for their reviews of an
earlier version of the changes, which can be found at:-
Previous (now obsolete) version, provided here only for reference
by previous reviewers: http://cr.openjdk.java.net/~ysr/6668573/webrev.00/
Based on their comments, I have made some minor modifications, and the
latest webrev can be found below.
Latest version: http://cr.openjdk.java.net/~ysr/6668573/webrev.01/
Thanks for any new/re-reviews!
More information about the hotspot-gc-dev