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.
EVALUATION
Tuning mechanisms provided to deal with issue:
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.