RFR: 8319048: Monitor deflation unlink phase prolongs time to safepoint [v7]

[Aleksey Shipilev]

On Fri, 17 Nov 2023 12:48:07 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8319048-monitor-deflation-unlink
>>  - Merge branch 'master' into JDK-8319048-monitor-deflation-unlink
>>  - Move unlink_batch init to proper place
>>  - Add invariant checking
>>  - Merge branch 'master' into JDK-8319048-monitor-deflation-unlink
>>  - Fix test after recent test infra renames
>>  - Merge branch 'master' into JDK-8319048-monitor-deflation-unlink
>>  - Batch 500
>>  - Pre-final touchups
>>  - Option range and tests
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/3508a5d0...09863092
>
> src/hotspot/share/runtime/synchronizer.cpp line 108:
> 
>> 106:         unlinked_list->append(next);
>> 107:         next = next_next;
>> 108:         if (unlink_batch++ >= (size_t)MonitorUnlinkBatch) {
> 
> Previously we `break` on the `MonitorDeflationMax` which is a implicit limit of the number of deflations. Not as `MonitorUnlinkBatch` could be `MonitorDeflationMax-1` then we would could walk more links than needed. 
> 
> Overall I am unsure why we do not pass in deflated_count to unlink and break when the `unlink_count == deflated_count`. Maybe I am missing something and there can be more deflated monitors than  the deflation_count we get. If so it seems like both this and the previous implementation would miss unlinking deflated monitors.

Walking more links is fine. Good suggestion to just pass the `deflated_count` here! Let me do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16412#discussion_r1398995374