RFR(L): JDK-8229517: Support for optional asynchronous/buffered logging
david.holmes at oracle.com
Mon Mar 9 05:33:44 UTC 2020
On 5/03/2020 8:04 pm, Liu, Xin wrote:
> Hi, hotspot reviewers,
> Could you take a look at my webrev?
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229517
> Webrev: https://cr.openjdk.java.net/~xliu/8229517/01/webrev/
> Previously, we had discussion at runtime-dev. https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-February/038211.html
> I would like to continue it because I redo my implementation on the tip of jdk and have made it a general solution.
Not a review as such but a couple of comments/queries.
The async logging is done as a periodic task that will be executed the
Watcher thread. This task requires a mutex that is also used by the
other threads doing the log operations. So potentially the watcher
thread could experience a significant delay waiting for the mutex.
I'm not clear what the actual lifecycle of the LogAsyncFlusher instance
is. I would have expected a single instance initialized at VM startup
and cleaned up at VM exit. The code gives the appearance that this can
actually be much more dynamic with multiple instances coming and going
through the lifetime of the VM. Deletion of the instance is particularly
problematic due to the Mutex, which has to be guaranteed not to be
accessed when it gets deleted.
> This webrev provides <logging/asynclog.hpp> on apar with <log.hpp>. Even though it doesn’t touch any existing logging calls, it’s very possible to offload any callsite of logging to the asynchronous buffer.
> My rationale is that we only need to redirect some time-critical logs to asynchronous buffer to dodge unexpected filesystem delay. Eg. g1gc has some loggings at safepoint. We mitigate those long-tailed GC latencies rooted by filesystem writing to gclog.
So this isn't an opt-in facility at runtime, but rather something that
has to be decided a-priori by the developer.
How does this interact with the synchronous logging that may be used for
a given set of log tags?
> I got feedback from my our internal users. They have a concern about my approach of dynamic memory. Indeed, I gave up ringbuffer design in previous version and turn to use a dynamic allocated linkedlist. If writing to filesystem stalls infinitely, JVM may implode because of memory usage. I plan to solve it by adding a memory quota to the FIFO of logAsyncFlusher.hpp. It will start dropping early messages of the FIFO if it has consumed too many free memories. Another potential improvement is changing the FIFO from mutex protected to lock-free. It make sense if we redirect high volume of logging messages to it and mutex becomes hot.
More information about the hotspot-dev