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

[Johan Sjölen]

On Thu, 28 Mar 2024 06:50:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 41 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ul-async-producer-consumer-take2
>>  - Missing N
>>  - Move constructors out of header file
>>  - Style
>>  - Correctly implement stalling
>>  - Missed one
>>  - Fix lossy conversions in tests
>>  - Merge remote-tracking branch 'origin/master' into ul-async-producer-consumer-take2
>>  - Only include sys/mman on Linux
>>  - Revert back to original Linux impl
>>  - ... and 31 more: https://git.openjdk.org/jdk/compare/804648d9...8c4ced0f
>
> src/hotspot/share/logging/circularStringBuffer.hpp line 119:
> 
>> 117:   PlatformMonitor& _stats_lock;
>> 118: 
>> 119:   // Can't use a Monitor here as we need a low-level API that can be used without Thread::current().
> 
> I had forgotten that the async logging thread already used a `PlatformMutex` and so had to go back to the original PR to understand why - see some initial discussion here:
> 
> https://github.com/openjdk/jdk/pull/3135#discussion_r629739367
> 
> The problem you now face is that by using monitors with explicit `wait()`'s for the stalling is that these will delay safepoints because the PlatformMonitor is not safepoint aware. I think you will need to introduce `ThreadBlockInVM` around potentially blocking enqueues - though it may not be that simple as you still need to address the logging that happens after the current thread has been deleted.

Thank you for finding the original comment thread. Wouldn't it be sufficient to add a `TBIVM` if and only if `Thread::current_or_null() != nullptr`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17757#discussion_r1547627748