JDK-6454265 : Customer requests a better way to control when the CMS collection could occur
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2006-07-28
  • Updated: 2011-02-16
  • Resolved: 2006-08-04
Related Reports
Duplicate :  
Description
Customer has excessive Minor GC durations / promotion rate into Tenured space.
A change in the JDK 1.5.0_06 was identified as the culprit - the change in the default MaxTenuringThreshold value from '31' to '15' . The MTT changed from 31 to 15 because the number of age bits was reduced as a result of the
biased-locking optimization. customer has tried to get back to the JDK 1.4.2 performance level by employing the CMS Collector, resulting in the following:

Recommendation 1:
Use CMS Collector with the final setting documented above.
Benefits:
1) No Full GC's
2) Minor Collections Timings 80-90 millisecond (10 millisecond improvement)
3) ~200-250 millisecond stop-the-world phase in total and ~2-3 seconds of concurrent phase with CPU overhead.
4) CMS Collection Interval ~4-5 hours.
5) Restarting of the JVM every week will be eliminated.

While the Minor GC durations are acceptable in this configuration, customer now has an overhead of ~200-250 millisecond stop-the-world phase in total and ~2-3 seconds of concurrent phase with CPU overhead. While this only occurs every 4 - 5 hours, there is no way to control when the CMS collection could occur, i.e. at peak business load. Further, there is the possibility that a Minor GC could immediately precede or follow the CMS Collection, resulting in close to a 350 millisecond pause, which is unacceptable. Therefore, customer requests that Sun perform 1 or 2, and 3, as outlined below:

         1. Relocate the Bit used for UseBiasedLocking, thus allowing enough bits for MTT to range up to 31 on value
         2. Add a new parameter that will indicate to the VM that any number above <New Parameter> will be considered as INFINITY. The idea behind this is that currently we have only ONE parameter. The Sun code says that we can define ANY threshold parameter. However, ANY Number above 15 will be considered INFINITE. Note that the INFINITE AGING RULE was introduced in 1.5 and looks at the SAME AGING PARAMETER. WE CAN SEPARATE the AGING AND INFINITE
AGING concerns BY INTRODUCING A NEW PARAMETER THAT WILL INDICATE THAT ANY AGE ABOVE THAT WILL BE CONSIDERED  INFINITE. Any age between 15 and that number (If Greater than 15) will be honored.
         3. Give the USER the control to invoke CMS. For applications that can detect "Idle" times, this will be useful to kick off CMS through the application.

Comments
EVALUATION The customer currently runs on dual processor boxes and the throughput impact of CMS during high trading volume periods is quite substantial (taking, as expected, 50% of the platform away from the application), and affecting throughput quite drastically. I believe it is possible to tune iCMS with a sufficiently low duty cycle ceiling so as to keep this in check and still be able to meet their pause time and throughput goals. The customer does not think so. But that discussion is beyond the scope of this RFE. The customer does not currently use CMS, as a result, so point #3 (and the synopsis of this RFE) are not germane to them from a production deployment perspective at this time. As such they do not seem interested in having CR 5025281 backported to Tiger. We explained to them why their requests #1 and #2 could not be met. The customer then agreed that this RFE could be closed without further action.
04-08-2006

EVALUATION We will be talking with the customer soon to obtain the needed information to resolve this CR.
02-08-2006