RFR: 8229517: Support for optional asynchronous/buffered logging [v16]
Volker Simonis
simonis at openjdk.java.net
Thu May 20 07:45:39 UTC 2021
On Wed, 19 May 2021 18:03:09 GMT, Xin Liu <xliu at openjdk.org> wrote:
>> src/hotspot/share/logging/logAsyncWriter.cpp line 180:
>>
>>> 178: // over all logging I/O.
>>> 179: for (LogTagSet* ts = LogTagSet::first(); ts != NULL; ts = ts->next()) {
>>> 180: ts->wait_until_no_readers();
>>
>> This loop is the only thing I'm not understanding in this whole PR but that doesn't mean it is wrong (it's probably just caused by my limited understanding of UL).
>> So why do we have to wait here until "there are no more readers" and what does that actually means? Is this necessary to prevent mixing log messages which have been printed before async logging was started?
>
> I would like to consolidate "exclusively". Once async logging takes over, we guarantee that no synchronous logsite is writing files in concurrency. If we guarantee that, we can avoid FileLocker() because only AsyncLog Thread writes files.
>
> Fence isn't enough here. fence can only guarantee that logsites 'after' the fence use async logging. It's possible that there are on-going synchronous logging.
>
> This is a RCU trick of Unified logging. RCU is kind of synchronization biased to multiple readers. `LogOutputList::Iterator` actually embeds an atomic counter.
> ts->wait_until_no_readers() waits until all readers finish. It means that all synchronous write have done.
>
> here is how synchronous log writes. Iterator increases to zero when the loop is done.
>
>
> void LogTagSet::log(LogLevelType level, const char* msg) {
> LogDecorations decorations(level, *this, _decorators);
> for (LogOutputList::Iterator it = _output_list.iterator(level); it != _output_list.end(); it++) {
> (*it)->write(decorations, msg);
> }
> }```
Thanks for the explanation. I assume you meant that the `Iterator` **de**creases the readers to zero when the loop is done. But I think I got it now.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3135
More information about the hotspot-dev
mailing list