RFR: 8323807: Async UL: Add a stalling mode to async UL [v6]

[Johan Sjölen]

On Wed, 22 May 2024 16:18:32 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR does two things for the asynchronous UL mode:
>> 
>> 1. Replaces the ping-pong buffers with a circular buffer.
>> 2. Adds a `stall` mode to async UL, ensuring that no messages are ever dropped if the log message producers out pace the log message writing thread.
>> 
>> These changes have been discussed on the hotspot-dev mailing list under the thread name "Request for Comment: Add a stalling mode to asynchronous UL". Xin Liu, the original author of the ping-pong approach, has confirmed that switching to circular buffers leads to a reduced rate of dropped messages.
>> 
>> The ticket description and my original e-mail contain approximately the same information and I'd recommend that you read either of those if you want an overview of why these changes are made and what the high-level protocol is.
>> 
>> All the best,
>> Johan
>
> Johan Sjölen 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 58 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into ul-async-producer-consumer-take2
>  - Merge remote-tracking branch 'origin/master' into ul-async-producer-consumer-take2
>  - Do not let go of producer lock when stalling
>  - Just inline it.
>  - TBIVM and small refactor
>  - Reflect renamings in tests
>  - Move more towards producer/consumer and fix alignment
>  - change to producer consumer in comment
>  - Rename to maybe_has_message
>  - Atomic::store for _tail/_head in locked methods
>  - ... and 48 more: https://git.openjdk.org/jdk/compare/2fc38c99...0e87ea10

A month and a bit of leaving this be made me realise that we can fix the starvation issue by having the stalling thread hold the producer lock and waiting on the consumer monitor's condition variable. Very small adjustment. This causes all producers to have to await enough memory being available for the sole producer with the (potentially large message).

We can also avoid doing the buffer copying by having 'transactions' through passing along a functor to enqueueing and dequeueing functions, but I think that can wait for a separate RFE.

I was considering a lock-free linked list approach, as this makes all threads independent of each other and avoids the need for a fixed-size buffer, but implementing lock-free linked lists with full insertion/deletion isn't trivial. We don't need to whip out that for async UL, I think.

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

PR Comment: https://git.openjdk.org/jdk/pull/17757#issuecomment-2125304116