JDK-8149442 : MonitorInUseLists should be on by default, deflate idle monitors taking too long
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-02-09
  • Updated: 2019-05-30
  • Resolved: 2016-04-27
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 9
9 b120Fixed
Related Reports
Relates :  
JDK-8153224 - Monitor deflation prolong safepoints
Relates :  
JDK-6852873 - Increase in delta between application stopped time and ParNew GC time over application lifetime
Description
ObjectSynchronizer::deflate_idle_monitors during safepoint "cleanup" may cause undue latency during STW phase. Enabling MonitorInUseLists alllows more efficient deflate of only potentially in-use monitors, rather than the entire (immortal) population.
Comments
[~dholmes]: I double checked with Karen regarding JDK-685273, she was mostly concerned with the "MonitorBound" option.
08-03-2016
Thanks for checking that.
08-03-2016
I did a series of tests on SPECjbb2013, SPECjEnterprise2010, and others, and my evaluation is that MonitorInUseLists is *safe* to enable as default, whereas MonitorBound easily can cause threads to run out of provisioned monitors quickly, leading to (potentially extreme) contention on the global monitor lists if tuned too hard. Analysis of monitor inflation usage patterns suggests SPECjbb2013 exhibits a "worst case" behavior for what MonitorInUseLists attempts to achieve: it inflates ~300K monitors/s, quickly lets them go (FJP!) and most[1] are deflated at every safepoint, i.e., the # monitors in use is ~= to total # monitors, thus SPECjbb2013 should see limited gain from this flag and should be well suited to expose any performance costs of using this flag. No significant regression has been seen (-0.7%, p=0.588). In the derby case, a baseline run create a population of around ~75k monitors during setup, then hardly use any during the benchmark measurement phase. This is a "best case" scenario for this flag since the time spent scanning monitors during safepoints drops significantly and monitors are quickly recycled. Sadly this doesn't reflect as a significant improvement in overall score (although it's quite close to the mark:+0.5%, p=0.03), although perf.counters indicate a 15-20% improvement in safepointSyncTime: Baseline: sun.rt.safepointSyncTime=662629129 sun.rt.safepointTime=17301464831 sun.rt.safepoints=848 sun.rt._sync_Inflations=4255015 sun.rt._sync_MonExtant=75136 -XX:+MonitorInUseLists sun.rt.safepointSyncTime=518315935 sun.rt.safepointTime=17258435813 sun.rt.safepoints=781 sun.rt._sync_Inflations=4249971 sun.rt._sync_MonExtant=6 I wonder if MonExtant might be lying, though. [1] Except the unused monitors that might be on the thread local freelist, which will approach ~500 per thread in this benchmark, see JDK-7021979 ...
11-02-2016
This needs detailed investigation and evaluation across a range of applications. As Karen wrote in JDK-6852873: "Incorrect use of these flags can cause noticeable issues."
10-02-2016