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

[Aleksey Shipilev]

On Mon, 20 Nov 2023 22:14:08 GMT, Daniel D. Daugherty <dcubed 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 15 additional commits since the last revision:
>> 
>>  - No need for vm.flagless
>>  - Use precise deflated_count
>>  - Rework option handling
>>  - Merge branch 'master' into JDK-8319048-monitor-deflation-unlink
>>  - 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
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/b7fd4e0e...5c41e46e
>
> src/hotspot/share/runtime/synchronizer.cpp line 122:
> 
>> 120:           // walks searching for new prev during unlink under heavy list inserts.
>> 121:           break;
>> 122:         }
> 
> Is there a reason to make this check and bail out while executing the `do ... while`
> and gathering the first batch of deflated monitors? Why can't you finish gathering
> your first batch and let the head change logic below just take care of it?

My thinking was two-fold: a) small batch size saves us from TTSP hiccup in gathering loop, but under heavy inserts we might end up searching for batch head through a long list -- and that is where small batch size would not save us; b) since `prev != nullptr` after the first update, we do not incur lots of overheads with checking in the gathering loop.

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

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