RFR: 8352568: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm

[David Holmes]

On Tue, 8 Apr 2025 12:41:58 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

> Hi,
> 
> The test for dropping messages have started to fail on aarch64 fast debug on Linux only when run as part of a test group. This seems to be a multi-threading issue with the `BufferUpdater`. When the `BufferUpdater` is removed, the issue disappears. This PR changes the code in a few other ways as well:
> 
> 1. Fail if the asynchronous mode isn't "drop" (the test makes no sense with stalling mode)
> 2. Print the entirety of the log file produced if no missing messages are found
> 3. If the thread running the test is unattached, then async UL will emit log messages in synchronous mode. Therefore, if the thread is unattached, the test now fails with an error message.
> 
> If the test fails in the future, then these will give important diagnostic information regarding the state of the test.
> 
> This is a re-worked version of https://github.com/openjdk/jdk/pull/24411

Okay, so `AsyncLogWriter::write` will do:

_buffer_staging->iterator();
while (it.hasNext()) {
    const Message* e = it.next();
   ...

lock-free AFAICS. And concurrently we could have:

AsyncLogWriter::BufferUpdater::~BufferUpdater() {
  AsyncLogWriter::flush();
  auto p = AsyncLogWriter::_instance;

  {
    ConsumerLocker clocker;

    delete p->_buffer;
    delete p->_buffer_staging;   <= DELETES THE BUFFER BEING ITERATED
    p->_buffer = _buf1;
    p->_buffer_staging = _buf2;
  }
}

I would have expected to see crashes from this rather than the presented failure mode, but I guess exactly what the iterating thread encounters is indeterminate.

Getting rid of BufferUpdater seems reasonable.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24508#pullrequestreview-2766948192