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

[Aleksey Shipilev]

On Fri, 14 Apr 2023 17:26:17 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> 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 :)
>
> Ok, glad we agree on that one now :)
> 
> However, I just realized that with the explicit flag you now do not reset `_no_progress_cnt` back to zero in the case where you do deflate monitors in a round triggered by `GuaranteedAsyncDeflationInterval`. Wouldn't it be better to do that?

No, I don't think so, mostly because this patch tries to build something that: a) works reliably; b) does not break other stuff accidentally. Let's isolate the triggers instead of trying to make sure they work together well.

Consider a case where there is a sequence of several no-progress threshold cleanups, this would normally collect enough `_no_progress_cnt`-s to bump the threshold ceiling in order to break the sequence. Note that no-progress means we tried to deflate, but deflated none. So if there is a guaranteed cleanup in the middle of that sequence which drops `_no_progress_cnt = 0` and still does not deflate anything (which is likely), the threshold cleanup code would start another series of cleanups from the beginning. And this is the simplest interaction example I can think of...

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

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