You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2016/06/24 00:10:16 UTC
[jira] [Comment Edited] (LOG4J2-1349) Garbage-free ThreadContext
map and stack
[ https://issues.apache.org/jira/browse/LOG4J2-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15346312#comment-15346312 ]
Remko Popma edited comment on LOG4J2-1349 at 6/24/16 12:09 AM:
---------------------------------------------------------------
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 getKeyAt(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 (although it may not be garbage-free).
was (Author: remkop@yahoo.com):
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