The basic high level idea is to maintain a cyclical fixed size in-memory buffer into which JVM threads would log at full-speed (i.e. the asynchronous logging would ideally not constrain the full concurrency supported by the existing implementation without asynchronous logging). A new demon thread would eagerly flush the log payload to the associated log output stream.
In one post-JDK 8 based implementation, support exists for Unified Logging, with the attendant constraints on concurrency of Unified Logging designed to avoid arbitrary interleaving of logging payload to a specific logging stream. In one JDK 8 based implementation, support exists for GC logging with possibly higher levels of logging concurrency than in the aforementioned Unified Logging case, and with no change in the interleaving semantics of log messages to the GC log file.
Other alternative implementations are possible.
As described in the email, there are a few alternative existing implementations on various vintages of the JVM.
This ticket is a placeholder to share a couple of different patches from various alternative existing implementations, so that we can collaboratively work towards creating one that can be subjected to the usual code review process in due course.
Specific sub-tickets will be created in the fullness of time for specific backports as needed, as the implementation matures into reviewable state.
|update manpage for -Xlog:async||Resolved|
|Release Note: Unified Logging Supports Asynchronous Log Flushing||Resolved|