RFR (L): 8046148: JEP 158 Unified JVM Logging

[Kirk Pepperdine]

>> 
>> I’m not so happy with the mixing of levels and tags and decorators and the other things in there. High performance journaling requires that you get out of the way and stay out of the way.
> 
> I don’t think the target has ever been a “high performance journaling” system. We have JFR for that use case.

JFR is a commercial product so I’m not sure how it fits into decisions about an source project.

My point wasn’t that the JVM provide high performance journaling, my point was that journaling, messaging and logging are all different flavors of the same activity and that there lessons that can be learned and applied from the other like activities. Further more, GC logging is currently part of the STW cost so having something that gets out of the way will be a huge benefit across the board. I know that the write is detached from the producer but even so, slow logging can cause things to back up. My extreme example is an application where 4.3 seconds of a 4.5 second time budget was spent in Log4J’s async adaptor! I have plenty other examples where logging is the prime consumer of the latency budget in an application at moderate rates of logging and that happens irregardless of the logging framework in use. Why I suggested to take a look at Chronicle is because it can log/message at very high rates, much much higher than any of the other logging frameworks without inflicting significant latency of the logging thread. I’m not suggesting that high performance logging is a hard requirement but if you can get there with the same effort why would you not want to go down that path? Machine go fast, you just need to get out of the way.

Kind regards,
Kirk