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

[Xin Liu]

On Thu, 13 May 2021 06:37:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on Windows.
>>   
>>   It seems that headers on Windows define WAIT_TIMEOUT somewhere. rename it.
>
> src/hotspot/share/logging/logAsyncFlusher.cpp line 40:
> 
>> 38: 
>> 39: void LogAsyncFlusher::enqueue_impl(const AsyncLogMessage& msg) {
>> 40:   assert_lock_strong(&_lock);
> 
> Can we enqueue (so, log) from within the async logger itself? If not, add an assert here that this should not be called from the logger thread?

enqueue_impl() is private. it's not accessible from outside. 
only public member functions can be seen by clients.

> src/hotspot/share/logging/logAsyncFlusher.cpp line 102:
> 
>> 100:     _stats(17 /*table_size*/) {
>> 101:   if (os::create_thread(this, os::asynclog_thread)) {
>> 102:     os::start_thread(this);
> 
> Here is some error handling needed if thread creation failed. UL should drop to sync mode then.

make sense! I will take a look at the error handling.

> src/hotspot/share/logging/logAsyncFlusher.cpp line 135:
> 
>> 133:   LinkedListImpl<AsyncLogMessage, ResourceObj::C_HEAP, mtLogging> logs;
>> 134: 
>> 135:   if (with_lock) { // critical area
> 
> I think the trick to get conditional Mutexes without having separate branches is to make the MutexLocker argument itself conditional (I think you can pass NULL, in which case no locking) - then you could merge these two branches.

thank you for the head-up!
MutexLocker can take NULL and drive through!  definitely worth a shot. 
Interestingly, MonitorLocker can't do that.

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

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