Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Thu, 23 Jun 2016 11:56:16 +0000 (UTC)
From: "Remko Popma (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12955454.1459557241000.9123.1466682976290@Atlassian.JIRA>
In-Reply-To: <JIRA.12955454.1459557241000@Atlassian.JIRA>
References: <JIRA.12955454.1459557241000@Atlassian.JIRA> <JIRA.12955454.1459557241545@arcas>
Subject: [jira] [Commented] (LOG4J2-1349) Garbage-free ThreadContext map and
 stack
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 23 Jun 2016 11:56:18 -0000


    [ 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, somevalue).

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:
{code}
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);
}
{code}

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
(v6.3.4#6332)

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