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

[Thomas Stuefe]

On Wed, 12 May 2021 21:37:24 GMT, Xin Liu <xliu at openjdk.org> wrote:

> > IIUC the mechanism you signal "async"-ness to the logging callsites with is via this pointer being NULL or not, right?
> 
> yes.
> 
> > I am not sure this is safe wrt to lost log output on termination.
> 
> It's not safe! now it may lose a coupe of messages in race condition. I have a patch to fix that.
> 
> > Thinking this through, one could even scratch the LogAsyncBuffer dynamic allocation and make it either a static
> > global object or even an AllStatic, with all static methods.
> 
> I tried this as well. I found it's hard. Logging sites spread the entire lifecycle of JVM. Unfortunately, async logging can't be in function without some runtime supports, such as Thread::current(), threading. One lesson I learned from this patch is that DON'T use any runtime in such low-level module.
> 
> Now my target is to define a clear interval. Between 2 synchronization points, async logging takes over synchronous logging. I think it's acceptable because it covers the entire "java" runtime which is concerned by Java applications.
> 
> ```
> |JVM begin---LogAsyncFlusher::initialize()---...---LogAsyncFlusher::terminate()--JVM End|
> ```

That's fine.

> 
> Another bonus for this 2-point-design is that we can assume only AsyncLog Thread is doing logging I/O when async logging is in charge. it means I can skip the FileLocker imposed by unified logging framework.

Which is good, but you have to find a solution for log sites which do not fulfill conditions to be logged asynchronously, if they fall into the live phase, see my comment above.

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

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