JDK-6852873 : Increase in delta between application stopped time and ParNew GC time over application lifetime
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u2,6u4,6u16
  • Priority: P2
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux,solaris_10
  • CPU: x86,sparc
  • Submitted: 2009-06-19
  • Updated: 2019-09-13
  • Resolved: 2010-10-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u19-revFixed 7Fixed hs16.2Fixed
Related Reports
Duplicate :  
JDK-6747415 - JVM: java 6u4~ use larger C heap if there are many threads
Duplicate :  
JDK-6550161 - VM crash during intensive class loading
Relates :  
JDK-6933076 - scavanging times increase after every Full GC
Relates :  
JDK-6964164 - +MonitorInUseLists can cause leakage of contended objects
Relates :  
JDK-6933402 - RFE: Improve PrintSafepointStatistics output to track cleanup time
Relates :  
JDK-8230938 - Deprecate MonitorBound
Relates :  
JDK-6782663 - Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate
Relates :  
JDK-8149442 - MonitorInUseLists should be on by default, deflate idle monitors taking too long
Description
The time delta defined by Application Stopped Time - ParNew GC time appears to increase over the duration of application lifetime. This time delta is not completely explained by safepoint time.

There seems to be a correlation with Resident Set Size (RSS). As RSS grows so does the delta.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b96a3e44582f
03-06-2010
EVALUATION http://hg.openjdk.java.net/hsx/hsx17/master/rev/66d7ba180c77
17-04-2010
EVALUATION http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/66d7ba180c77
16-04-2010
EVALUATION We will be adding two new flags to allow tuning the time spent in monitor deflation. The flags will initially default to off. Two new flags for controlling the behaviour of the monitor cleanup: -XX:+MonitorInUseLists -XX:MonitorBound=# Monitors are basically inflated when locks are contended or when an application uses wait/notify. The clean up time seen at safepoint's, which is called out as "deflating idle monitors" is time spent cleaning up monitors that are no longer in active use. The jvm does not clean them up when they exit the monitor so as to minimize overhead of the lock/unlock paths, they are cleaned at a later safepoint. These flags explicitly adjust the determination of that occurrence. -XX:+MonitorInUseLists : The goal of this flag is to explicitly track which monitors are in use, which includes active use and idle. If the application generally has fewer monitors in use than the maximum they ever required at a time, then this flag may help. -XX:MonitorBound=# : tune the # selected by using output from detailed safepoint timings *see 6933402. start with #threads * # locks per thread at a steady state, Making the number too small will cause too frequent safepoints. Incorrect use of these flags can cause noticeable issues. *** (#1 of 1): 2010-03-23 09:33:34 EDT ###@###.###
27-03-2010
EVALUATION Data from SR2 customer indicates that the delta can be entirely attributed to monitor deflation cost. More data is being collected to confirm root cause, and inform possible fixes to ameliorate/amortize the costs.
17-03-2010
SUGGESTED FIX I have a proposed change attached in the bug report. See webrev.zip for the solution. Basically, the fix will contain: 1. More precise vm operation time. Currently, it includes the clean up task time, now it should reflect the real time spent in vm operation such as GC or other activities. 2. Print out the break down of clean up task time, so we can understand which part of the clean up task takes the most time. 3. In summary part, I also printed out the longest VM operation time,so the customer can know the worst case of VM operation time.
09-03-2010
EVALUATION It seems that adding this extra information regarding time spent in clean up tasks will really help customer understand the discrepancy. I am working on a patch now.
09-03-2010
EVALUATION Is this still an immediate concern for the customer?
25-08-2009