logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1349) Garbage-free ThreadContext map and stack
Date Thu, 23 Jun 2016 11:56:16 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15346312#comment-15346312

Remko Popma commented on LOG4J2-1349:

The current {{ThreadContext}} map implementation is a copy-on-write data structure. This is
efficient because the number of _reads_ vastly outnumbers the number of _writes_. Every time
a message is logged, the current ThreadContext map is passed to the LogEvent as is. This is
safe because this map is immutable: it is replaced, not modified, when the user calls ThreadContext.put(key,

The drawback is that a copy-on-write data structure is not garbage-free. 

A garbage-free ThreadContext map would have to be a mutable data structure. To ensure that
LogEvents can safely be passed off to other threads, the LogEvent cannot have a direct reference
to the ThreadContext map. Instead, the data from the ThreadContext map would need to be copied
into the LogEvent's context map.

For this to be garbage-free, LogEvent needs a different data structure to carry context map
data. Currently LogEvent implementations use a {{java.util.Map<String, String>}} for
this. The JDK Map is not an easy data structure to make garbage-free. It would also be nice
to have the ability in LogEvent to carry data of any type.

One idea is to introduce a small interface that is general enough to be map-like but can be
implemented in a garbage-free manner. 

LogEvent implementations would have an instance of this interface instead of the current {{java.util.Map<String,
String> contextMap}} attribute.

Something like this:
interface CustomData<K, V> {
    /** Called to implement {@link LogEvent#getContextMap()}. */
    Map<String, String> asMap();

    /** Put key-value pair into the table.
        Remove key if value is null. */
    void put(K key, V value);

    /** Returns the value for the specified key. */
    V getValue(K key);

    /** Number of key-value pairs. */
    int size();

    /** Removes all key-value pairs. */
    void clear();

// Instead of Iterators, use an index-based approach.

    /** Returns the index of the specified key. */
    int indexOfKey(K key);

    /** Returns the i-th key. */
    K getKey(int i);

    /** Returns the value for the i-th key. */
    V getValueAt(int i);

The LogEvent interface would have an additional method {{getCustomData() : CustomData<K,
V>}} that gives downstream components direct access to the new data structure. Existing
downstream components would still be able to call {{logEvent.getContextMap()}} to get a {{Map<String,
String>}} view of the context map data and this would work as expected.

> Garbage-free ThreadContext map and stack
> ----------------------------------------
>                 Key: LOG4J2-1349
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1349
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.5
>            Reporter: Remko Popma
>             Fix For: 2.7
> The current ThreadContext map and stack implementations allocate temporary objects. This
ticket is to investigate and track the work for alternative implementations that are garbage-free.
> Both DefaultThreadContextMap and DefaultThreadContextStack are copy-on-write data structures:
each modification replaces the ThreadLocal object with a modified copy. The advantage of this
approach is that there is no need to make a copy for each LogEvent.
> Also, DefaultThreadContextMap uses a JDK map, the JDK collections tend to allocate a
lot of temporary objects.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message