Remko Popma created LOG4J2-1270:
-----------------------------------
Summary: Garbage-free steady-state logging
Key: LOG4J2-1270
URL: https://issues.apache.org/jira/browse/LOG4J2-1270
Project: Log4j 2
Issue Type: New Feature
Components: API, Appenders, Core, Layouts, Pattern Converters
Affects Versions: 2.5
Reporter: Remko Popma
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]
