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

[Axel Boldt-Christmas]

On Mon, 20 Nov 2023 11:19:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> 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.

I feel like the batch unlinking and the incremental polling are orthogonal issues. 

Batch unlinking is an optimisation that can be implemented regardless of how often we poll. Regardless seem like the dominating factor will be walking the links, not performing relaxed atomic stores. The CAS can also be relaxed here as we are only unlinking already added ObjectMonitors. And after the first failed CAS we stop CASing and will just keep updating links. (We only need release when adding to the list, and acquire when taking the head). Regardless I added batching to my POC. But it still polls for every deflate+unlink cycle. This still results in less polls than with #16412 and #16738 together. 

To me it seems like the polling acquire is the costly part if the loop body does very little work. So maybe some inner loop could be used for both the deflate+unlink and the purge/delete. Here there is a tradeoff between achievable OM churn and time to safepoint.

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

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