[
https://issues.apache.org/jira/browse/LOG4J2-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150284#comment-15150284
]
Remko Popma commented on LOG4J2-1270:
-------------------------------------
Running the Classic test with NoGcMessage instead of ParameterizedMessage
(creating a new instance for each log event) gives this:
{code}
Classic[0] (2016-02-17 19:27:41.736) took 1,217,075,427 ns. CHECK=1113dda30
Classic[1] (2016-02-17 19:27:43.055) took 1,132,891,852 ns. CHECK=1113dda30
Classic[2] (2016-02-17 19:27:44.289) took 1,111,914,933 ns. CHECK=1113dda30
Classic[3] (2016-02-17 19:27:45.509) took 996,953,620 ns. CHECK=1113dda30
Classic[4] (2016-02-17 19:27:46.603) took 1,006,936,160 ns. CHECK=1113dda30
Classic[5] (2016-02-17 19:27:47.710) took 1,001,869,726 ns. CHECK=1113dda30
Classic[6] (2016-02-17 19:27:48.814) took 1,063,575,531 ns. CHECK=1113dda30
Classic[7] (2016-02-17 19:27:49.986) took 1,183,842,955 ns. CHECK=1113dda30
Classic[8] (2016-02-17 19:27:51.267) took 1,076,177,619 ns. CHECK=1113dda30
Classic[9] (2016-02-17 19:27:52.452) took 1,024,451,338 ns. CHECK=1113dda30
(539 minor GC occurrences averaging 400 us user time)
{code}
This tells me two things:
* Optimizing the Message implementation (LOG4J2-1271) can give some significant
performance gains.
* This is not the only factor, and it is still worth spending effort on
reducing object allocation rate: fewer GC pauses make a large difference.
> Garbage-free steady-state logging
> ---------------------------------
>
> Key: LOG4J2-1270
> URL: https://issues.apache.org/jira/browse/LOG4J2-1270
> Project: Log4j 2
> Issue Type: Epic
> Components: API, Appenders, Core, Layouts, Pattern Converters
> Affects Versions: 2.5
> Reporter: Remko Popma
> Labels: gc
>
> In certain fields like finance, predictable latency is very important, and
> applications in this space tend to carefully manage their object allocation
> to avoid unpredictable GC pauses. As of 2.5, Log4j is not suitable to be
> included in such applications since it allocates new objects while running in
> its steady state.
> This ticket is to investigate the feasibility of modifying some key
> components in Log4j to provide a configuration that does not allocate new
> objects in its steady state. (Initialization or shutdown don't need to be
> allocation-free.)
> To clarify, I am not proposing to make all of Log4j allocation-free. My goal
> is to create an allocation-free execution path in Log4j with some reasonable
> subset of the Log4j functionality. For example, make logging garbage-free if
> all of these conditions are met:
> * all loggers are AsyncLoggers
> * you only use the RandomAccessFileAppender
> * you only use a PatternLayout without any regular expression replacements,
> without lookups and with one of the pre-defined date formats.
> Further restrictions may be necessary.
> AsyncLogger already has a ring buffer of pre-allocated LogEvents, so some of
> the work here is already done.
> Components that currently allocate objects in the critical path:
> # (API) Logger methods with vararg parameters
> # (API) All MessageFactory implementations
> # LoggerConfig.getProperties (if non-null) - wraps in
> Collections.unmodifiableMap
> # RingBufferLogEvent.mergePropertiesIntoContextMap (if LoggerConfig
> properties is non-null)
> # LoggerConfig.callAppenders (for-each loop over CopyOnWriteArraySet creates
> iterator)
> # Layout.toByteArray(LogEvent) - this API makes it difficult to avoid
> allocating a new byte[] array for each log event
> # AbstractStringLayout.toByteArray() - turns each LogEvent into a new String
> before turning the String into a byte[] array
> # DatePatternConverter - new CachedTime if event.millis differs from previous
> event
> # DatePatternConverter.CachedTime - new String caching the result
> # FixedDateFormat - new char[] array
> # (FastDateFormat - for each event: new GregorianCalendar, new StringBuilder,
> new char[], new String)
> # String.getBytes - creates initial byte array, CharBuffer, ByteBuffer,
> trimmed resulting byte array
> The Layout API and turning Strings into bytes are probably the most tricky
> areas. One advantage of restricting ourselves to async logging is that there
> is only a single background thread that does all the formatting and I/O, so
> we don't have to worry about concurrency issues when re-using buffers etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
