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

[Thomas Stuefe]

On Thu, 13 May 2021 07:28:27 GMT, Xin Liu <xliu at openjdk.org> wrote:

>>> One thing occurring to me was that a global buffer for all outputs is maybe not the best choice. One buffer per LogFileOutput seems like a cleaner, more natural fit:
>> 
>> That's another reason I introduce a hashmap for dropped counters.
>> 
>> I read you in the RFC thread about the "Global Big Lock" for all filed-based log outputs.  I know it's not scalable.I proposed to Volker splitting buffers for different outputs. Then the cost of synchronization would be effectively same as current UL. Volker countered that it wasn't an issue until users deploys many log files. it seems rare. We can leave it for future improvement.
>
> I think what Volker said makes sense, then `KVHashtable<LogFileOutput*, AsyncLogBuffer&>` downsized to 
> `KVHashtable<LogFileOutput*, uint32_t>`...

> > One thing occurring to me was that a global buffer for all outputs is maybe not the best choice. One buffer per LogFileOutput seems like a cleaner, more natural fit:
> 
> That's another reason I introduce a hashmap for dropped counters.
> 
> I read you in the RFC thread about the "Global Big Lock" for all filed-based log outputs. I know it's not scalable.I proposed to Volker splitting buffers for different outputs. Then the cost of synchronization would be effectively same as current UL. Volker countered that it wasn't an issue until users deploys many log files. it seems rare. We can leave it for future improvement.

Performance was not my main reason for suggesting this, but code simplicity.

Im fine with leaving this for a future RFE

Fior the record, here is the idea:
- keep async buffer, drop counter and async buffer lock as members in LogFileOutput
- have a global counter "enqueued-items"
- in LogFileOutput::write:
  - if enqueued-items=max, increase the drop counter in LogFileOutput
  - otherwise create buffer if needed, then enqueue into this buffer, increase global enqueued-items counter
- LogAsyncFlusher::flush becomes LogFileOutput::flush_async_buffer() or similar and:
  - prints its drop counter, if > 0
  - flushes its own buffer, same logic as today, but locks over its local _async_buffer_log
  - and decreases global enqueued-items counter
- flushing means iterating over all LogFileOutput objects and calling flush on them.


> I think what Volker said makes sense, then `KVHashtable<LogFileOutput*, AsyncLogBuffer&>` downsized to
> `KVHashtable<LogFileOutput*, uint32_t>`...

I'm loosing track here, where is Volker's remark and where is the first variant used?

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

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