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

[Xin Liu]

On Tue, 6 Apr 2021 07:05:57 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi Xin,
> 
> From the algorithm perspective all loggers are readers.
> We are protecting the buffer pointer which only the flusher writes to.
> To make sure not one still sees the old buffer after the storing of the swapped in one we need to issue a write synchronize.
> When the write synchronize finishes we know that the to be flushed buffer is no longer visible.
> 
> That the readers of this buffer pointer writes into the buffer doesn't matter since they can only write if they can see the buffer.
> When no reader can see the buffer, they can not write to it either.
> 
> I do not follow your reasoning on atomic increment.
> 
>     * This change-set have:
>       `  { // critical area MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); enqueue_impl(m);   }`
> 
>     * A lock free linked list is most often implemented with CAS.
> 
> 
> Both CAS and above mutex serialization are more expensive atomic inc.
> 
> If you feel that your current code is battle-proven and you think doing additional enhancements as incremental changes is better, please do so. As I said, I don't have any big concern about either performance nor blocking the the VM thread.

Hi, Robin,

Now I understand "From the algorithm perspective all loggers are readers".  `LogOutputList` uses the similar idea and I do leverage it when obtaining lock is inappropriate in this PR.  

`GlobalCounter::write_synchronize()` is epoch-based RCU for "safe memory reclamation".  It's intriguing to use in a ping-pang buffer and now I see it's correct! I am very interested in it and let me try it out after this PR.  I feel sorry that my reflection arc is so long.  I have to read and understand a lot of hotspot runtime code, which is not easy for me.  

For "the most expensive synchronization is atomic_incrementation."  I mean we need to atomic increase the writing pointer of a buffer no matter what. It should be the most expensive "cost".  Yes, I acknowledge that atomic operations are cheaper than CAS or mutex.  

So far, I am fine with the performance(it's not my intention to writing a "high-performance" logging), but I feel it's quite cumbersome to use Mutex given the fact that its ranking is stiff.  GlobalCounter+ping-pang buffer should result in a more concise and efficient implementation.   

thanks,
--lx

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

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