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

[Aleksey Shipilev]

On Fri, 17 Nov 2023 14:13:42 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> That seems to remove the need for the new JVM flag as well as the existing MonitorDeflationMax that really was just added to deal with GrowableArray length being an int. 

I am not at all sure that is the only concern batching resolves.  The speed with which we unlink determines how much of the OM churn we can sustain. The CASes on `_head` and volatile stores on `_next_om` are also a concern that batching alleviates. Otherwise I would have just throw away the entire batching code from here, and just poll for safepoint after every unlinked monitor. Note that current batching code basically does a single `_head` CAS when needed, and then just moves on locally deleting the in-use list links. If there is OM churn, it means `_head` gets mutated often by insertions, so in worst case we are incurring contended CASes during unlink if we are not careful. IMO, any solution should take that into account.

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

PR Comment: https://git.openjdk.org/jdk/pull/16412#issuecomment-1818859732