RFR: 8229517: Support for optional asynchronous/buffered logging [v19]

[Xin Liu]

On Mon, 24 May 2021 08:55:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The value of _sem denotes the number of messages have been enqueued.  It's actually different from "the number of messages in _buffer".  When  _sem.wait() returns, it just **de**creases one.  however, _buffer.pop_all() pops all messages in queue at once.   The two numbers are not consistent all the time. 
>> 
>>> Maybe "_sem denotes the number of messages in _buffer` and moving the two together?
>> 
>> Could you elaborate this?  thanks?
>
>> When _sem.wait() returns, it just decreases one. however, _buffer.pop_all() pops all messages in queue at once. The two numbers are not consistent all the time.
> 
> Thank you for the explanation. I overlooked the fact that the "consumer" clears out the buffer in bulk.
> 
>> Could you elaborate this? thanks?
> 
> I mean that "_sem is a semaphore whose value denotes how many messages have been enqueued" is a bit inaccurate, because `write()` will decrement the semaphore value. For example, a producer has enqueued 2 msgs, but `_sem` could be `0`, as `flush` has been called.
> 
> However, I don't see a easy way to "fix" this; I am OK with the current comment.

Technically, we can make _sem denotes "the number of messages in buffer". 
Semaphore.signal() can pass in an integer argument. It should increase the semaphore value count instead of just 1. 
I don't think it would help for performance but can avoid wasteful spin.  Let's do that later.

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

PR: https://git.openjdk.java.net/jdk/pull/3135