Bug ID: JDK-8256304 should MonitorUsedDeflationThreshold be experimental or diagnostic

Versions (Unresolved/Resolved/Fixed)

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 17
17 b24Fixed

[~coleenp] mentioned this RFE during the JDK-8253064 review: 

 src/hotspot/share/runtime/globals.hpp
          "The maximum number of monitors to deflate, unlink and delete "   \
          "at one time (minimum is 1024).")                      \
          range(1024, max_jint)                                             \
                                                                            \
  product(intx, MonitorUsedDeflationThreshold, 90, EXPERIMENTAL,            \
          "Percentage of used monitors before triggering deflation (0 is "  \
          "off). The check is performed on GuaranteedSafepointInterval "    \

Should there still be experimental options after this change?

@dcubed-ojdk

Robbin added MonitorUsedDeflationThreshold as an experimental
option back in JDK10. See the longer reply to David's comment.
I don't plan to change that option with this changeset.

Changeset: fe333431 Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2021-05-21 18:32:25 +0000 URL: https://git.openjdk.java.net/jdk/commit/fe333431c8c0f089e4fd55bf10903e1fba7fc6c4
21-05-2021
Change the option from "EXPERIMENTAL" to "DIAGNOSTIC" like the other monitor related options: $ git diff diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp index b3e082850f9..676255bf1b3 100644 --- a/src/hotspot/share/runtime/globals.hpp +++ b/src/hotspot/share/runtime/globals.hpp @@ -711,7 +711,7 @@ const intx ObjectAlignmentInBytes = 8; "at one time (minimum is 1024).") \ range(1024, max_jint) \ \ - product(intx, MonitorUsedDeflationThreshold, 90, EXPERIMENTAL, \ + product(intx, MonitorUsedDeflationThreshold, 90, DIAGNOSTIC, \ "Percentage of used monitors before triggering deflation (0 is " \ "off). The check is performed on GuaranteedSafepointInterval " \ "or AsyncDeflationInterval.") \
20-05-2021
I was looking for your [~dcubed] longer answer to David's comment but my comment was quite a bit simpler. Since all the values around MonitorUsedDeflationThreshold are DIAGNOSTIC options, I believe this one should be too. if (NoAsyncDeflationProgressMax != 0 && _no_progress_cnt >= NoAsyncDeflationProgressMax) { float remainder = (100.0 - MonitorUsedDeflationThreshold) / 100.0; size_t new_ceiling = ceiling + (ceiling * remainder) + 1; ObjectSynchronizer::set_in_use_list_ceiling(new_ceiling); log_info(monitorinflation)("Too many deflations without progress; " "bumping in_use_list_ceiling from " SIZE_FORMAT " to " SIZE_FORMAT, old_ceiling, new_ceiling); _no_progress_cnt = 0; ceiling = new_ceiling; } So if you're trying to diagnose some performance or other problem in product mode, you have to give -XX:+UnlockVMDiagnosticOptions -XX:NoAsyncDeflationProgressMax=something -XX:MonitorUsedDeflationThreshold=50 or something like that, without having to throw on the -XX:+UnlockExperimentalVMOptions. Since the combination of these appear to be for diagnostic purposes.
06-05-2021
[~coleenp] - feel free to update the RFE's description as needed.
12-11-2020

Relates :	JDK-8181859 - Monitor deflation is not checked in cleanup path
Relates :	JDK-8264420 - Allow MonitorUsedDeflationThreshold=0 for aggressive deflation of all eligible monitors
Relates :	JDK-8253064 - monitor list simplifications and getting rid of TSM
Relates :	JDK-8226416 - MonitorUsedDeflationThreshold can cause repeated async deflation requests