EVALUATION

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

EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/master/rev/66d7ba180c77
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/66d7ba180c77
                                     

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 ###@###.###
                                     

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.
                                     

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.
                                     

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.
                                     

EVALUATION

Is this still an immediate concern for the customer?