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

[David Holmes]

On Wed, 13 Jan 2021 16:47:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   address dholmes CR comments.

A couple of minor comments.

Thanks,
David

src/hotspot/share/runtime/synchronizer.cpp line 1170:

> 1168:     float remainder = (100.0 - MonitorUsedDeflationThreshold) / 100.0;
> 1169:     size_t new_ceiling = ceiling + (ceiling * remainder) + 1;
> 1170:     size_t old_ceiling = ceiling;

Is that really what you want? `ceiling` may have been assigned again at line 1160.

test/hotspot/jtreg/runtime/Monitor/MonitorUsedDeflationThresholdTest.java line 48:

> 46:     public static final int DELAY_SECS = 10;
> 47:     public static int inflate_count = 0;
> 48:     public static Object monitors[];

Style nit: Object[] monitors;

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

Marked as reviewed by dholmes (Reviewer).

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