RFR: 8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests [v3]

[Daniel D.Daugherty]

> Adding support for a diagnostic option called NoAsyncDeflationProgressMax
> with a default value of 3. If we have three async monitor deflation cycles in a
> row with zero monitors deflated, then we adjust the in_use_list_ceiling up.
> 
> I've locally built and tested this fix on my MBP13 using the
> MonitorUsedDeflationThresholdTest.java test that I wrote when this issue
> first came up in June of 2019. I will be including this fix in my next Mach5
> Tier[1-3] testing batch.

Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8226416
 - change NoAsyncDeflationProgressMax from 'int' to 'uintx' and _no_progress_cnt from 'intx' to 'uintx'.
 - Merge branch 'JDK-8259349' into JDK-8226416
 - change AvgMonitorsPerThreadEstimate from int to size_t and _in_use_list_ceiling from jint to size_t.
 - Merge branch 'JDK-8259349' into JDK-8226416
 - dholmes CR - delete a stale comment.
 - Merge branch 'JDK-8259349' into JDK-8226416
 - delete bad assert found by linux build.
 - change NoAsyncDeflationProgressMax from 'intx' to 'int'; clarify logic in monitors_used_above_threshold(); add MonitorUsedDeflationThresholdTest.java.
 - Merge branch 'JDK-8259349' into JDK-8226416
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/c338f116...2efe7b4b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1993/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1993&range=02
  Stats: 171 lines in 3 files changed: 164 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1993.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1993/head:pull/1993

PR: https://git.openjdk.java.net/jdk/pull/1993