RFR: 8349755: Fix corner case issues in async UL [v14]

[Johan Sjölen]

On Thu, 13 Feb 2025 13:48:03 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> There are a few corner-cases when logging with asynchronous UL, all of which I'd like to fix with this PR.
>> 
>> 1. If the `AsyncLogWriter`  produces a log message,  then it'll deadlock as it'll wait for itself to release the `AsyncLogLock`.
>> 2. If a producing thread produces another log message while enqueueing, then a deadlock will occur
>> 
>> We fix this by keeping a thread as the owner of the lock. If the lock is owned by the current thread, then we resort to synchronous logging.
>> 
>> Note, this fix introduces a third case:
>> 
>> 3. If an unattached thread logs then there is no identity, so we cannot check if it holds the lock. We must therefore resort to synchronous logging in this case also
>> 
>> In UL, we have so far guaranteed Program-Order log message appearance. In other words, `log("A"); log("B");` is guaranteed to always appear in the order `AB` in the log output. For cases 1 and 3, we still keep this guarantee. However, for case 2 we break this guarantee. The recursive log message will appear before any unflushed log messages from the logging thread. As I see no simple way  of fixing this, along with the fact that this is highly unlikely to ever occur (this has never been observed in production), I've decided to break that guarantee and prioritize logs not being missing.
>> 
>> As it's preferable that we do not have recursive logging (as in case 2 and partially in case 1), I've decided to `assert` that these should not hold. In debug systems, during testing, we can find any accidental recursive logging. In production systems, we will handle this correctly by going back to synchronous logging.
>> 
>> Testing: GHA only, so far.
>> 
>> All the best,
>> Johan
>
> Johan Sjölen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - We ran pb again, and not pb2.
>  - Only log the message in single-log messages

Alright,

So I fixed the tests. The way I implemented the testing is a bit of a hack, but at least it's a local-to-UL hack.The checking function needs to know whether to crash or not and instead handle the message. In order to inform the function of this, we set a static bool variable to `true` earlier in the call stack.

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

PR Comment: https://git.openjdk.org/jdk/pull/23513#issuecomment-2656722215