RFR: 8362282: runtime/logging/StressAsyncUL.java failed with exitValue = 134

[David Holmes]

On Tue, 9 Sep 2025 11:28:41 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> During `AsyncLogWriter` initialization we previously published the global `AsyncLogWriter _instance` before waiting for existing synchronous logging activity to finish and before starting the async consumer thread. As soon as `_instance` became visible, `is_enqueue_allowed()` allowed new log calls to switch to the async path. Those calls bumped `LogOutputList`'s counters while `initialize()` was waiting for `wait_until_no_readers()` to observe no active readers. At the same time, because the consumer thread wasn’t yet running, producers could end up waiting for a consumer that didn’t exist. In rare timing, this created a circular wait that manifested as intermittent lock-ups in `StressAsyncUL.java`.
> 
> The initialization order is changed so that we do not make the async writer visible until after all pre-existing synchronous logging has completed. Concretely, `initialize()` now:
> 
> 1. waits for each `LogTagSet` to report no readers, ensuring synchronous logging is done,
> 2. publishes `_instance` with a release store so readers observe a fully initialized writer, and
> 3. immediately starts the async logging thread.
> 
> With this ordering, new async producers cannot keep the counters inflated while initialization is waiting. Any messages produced in the brief window between publishing `_instance` and the thread's first run are safely buffered and then consumed as soon as the thread starts.
> 
> Testing:
> - Oracle tiers 1-3
> - Repeated runs of `StressAsyncUL.java` with no observed lock-ups

Fix looks good. One minor nit. Thanks.

src/hotspot/share/logging/logAsyncWriter.cpp line 323:

> 321:     // We use LogOutputList's RCU counters to ensure all synchronous logsites have completed.
> 322:     // After that, we publish the initalized _instance to readers.
> 323:     // Then, start the AsyncLog Thread; It exclusively takes over all logging I/O.

Suggestion:

    // Then we start the AsyncLog Thread and it exclusively takes over all logging I/O.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27169#pullrequestreview-3204635598
PR Review Comment: https://git.openjdk.org/jdk/pull/27169#discussion_r2335715647