Request for review (S): 6668573: CMS: reference processing crash if ParallelCMSThreads > ParallelGCThreads

Y. Srinivas Ramakrishna y.s.ramakrishna at oracle.com
Mon Mar 14 23:43:39 UTC 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
object.

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!
-- ramki



More information about the hotspot-gc-dev mailing list