[jdk17] RFR: 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX [v6]

[David Holmes]

On Tue, 13 Jul 2021 10:20:49 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch solved the sempahore overflow issue with errno ERANGE or EOVERFLOW.
>> Previously, we have asymmetric p/v operations for semaphore _sem. Each iteration
>> only decrements _sem 1 but dequeues N messages. If logging threads keep preempting
>> async logging thread, it may cause the value of _sem accumulates until overflow! 
>> 
>> The patch corrects the value of _sem after write(). n messages are dequeued/processed.
>> We need to invoke _sem.wait() max(n-1, 1) time. This ensures that each iteration
>> decrements n instead of 1.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace counting semaphaore with  os::PlatformMonitor.

Sorry this isn't right at all.

David

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

> 161:       while (!_data_available) {
> 162:         _lock.signal();
> 163:         _cv.wait(0/* no timeout */);

You can't call wait() on an unlocked monitor  - that's not how monitors are used.

src/hotspot/share/logging/logAsyncWriter.hpp line 141:

> 139:   Semaphore _lock;
> 140:   Semaphore _flush_sem;
> 141:   os::PlatformMonitor _cv;

No this isn't what you need. The _lock is the PlatformMonitor. You lock/unlock in AsyncLogLocker for the critical regions, and then use the wait/notify operations for the coordination.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/216