[
https://issues.apache.org/jira/browse/LOG4J2-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15150422#comment-15150422
]
Remko Popma commented on LOG4J2-1270:
-------------------------------------
NoGC test after introducing ThreadLocal in the NoGCMessage class:
{code}
NoGC[0] (2016-02-17 21:24:36.227) took 922,766,470 ns. CHECK=1113dda30
NoGC[1] (2016-02-17 21:24:37.258) took 836,536,882 ns. CHECK=1113dda30
NoGC[2] (2016-02-17 21:24:38.195) took 794,610,817 ns. CHECK=1113dda30
NoGC[3] (2016-02-17 21:24:39.096) took 789,674,788 ns. CHECK=1113dda30
NoGC[4] (2016-02-17 21:24:39.982) took 789,142,304 ns. CHECK=1113dda30
NoGC[5] (2016-02-17 21:24:40.879) took 785,797,686 ns. CHECK=1113dda30
NoGC[6] (2016-02-17 21:24:41.765) took 798,985,989 ns. CHECK=1113dda30
NoGC[7] (2016-02-17 21:24:42.666) took 805,058,223 ns. CHECK=1113dda30
NoGC[8] (2016-02-17 21:24:43.565) took 779,291,375 ns. CHECK=1113dda30
NoGC[9] (2016-02-17 21:24:44.454) took 783,671,377 ns. CHECK=1113dda30
56 minor GC occurrences of 300-400us user time
{code}
> 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]
