United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6852873 Increase in delta between application stopped time and ParNew GC time over application lifetime
JDK-6852873 : Increase in delta between application stopped time and ParNew GC time over application lifetime

Details
Type:
Bug
Submit Date:
2009-06-19
Status:
Closed
Updated Date:
2013-07-18
Project Name:
JDK
Resolved Date:
2010-10-14
Component:
hotspot
OS:
linux,solaris_10
Sub-Component:
runtime
CPU:
x86,sparc
Priority:
P2
Resolution:
Won't Fix
Affected Versions:
6u2,6u4,6u16
Fixed Versions:
hs18

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

Is this still an immediate concern for the customer?
                                     
2009-08-25
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.
                                     
2010-03-09
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.
                                     
2010-03-09
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.
                                     
2010-03-17
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 ###@###.###
                                     
2010-03-27
EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/66d7ba180c77
                                     
2010-04-16
EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/master/rev/66d7ba180c77
                                     
2010-04-17
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b96a3e44582f
                                     
2010-06-03



Hardware and Software, Engineered to Work Together