RFR: 8305994: Guarantee eventual async monitor deflation [v2]

[Aleksey Shipilev]

On Fri, 14 Apr 2023 16:53:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The problem is here: https://github.com/openjdk/jdk/blob/1fd400608e9ea423a6e4f1797652bd02f027da1b/src/hotspot/share/runtime/synchronizer.cpp#L1072-L1073
>> 
>> Along with the reset of `_no_progress_cnt` in `monitors_used_above_threshold`, we *also* bump the ceiling, which means the next checks for used monitor thresholds get more and more unlikely to fire, because ceiling goes farther and farther away. You can clearly see that in the `-Xlog:monitordeflation` without the remediation like this: with every `NoAsyncDeflationProgressMax` guaranteed attempts, that block bumps the ceiling. :)
>
> I agree, I just don't understand why `--_no_progress_cnt` wouldn't have the same effect like your current solution? With `--_no_progress_cnt` in the block for the `GuaranteedAsyncDeflationInterval` case in `is_async_deflation_needed()` a call to `deflate_idle_monitors()` wouldn't increment the initial value of `_no_progress_cnt` which is exactly the same behavior you have now with the introduction of new `_no_progress_allow_updates` parameter.

Ah, I understand. Yes, decrement would work too. But I think the explicit flag is cleaner, if only it took me three comments to understand how would that work :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13474#discussion_r1167078314