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
Date Wed, 31 Aug 2016 11:36:20 GMT

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

Remko Popma commented on LOG4J2-1349:

Yes, these are the selected implementations that will all be used in production usage. The
OpenHashMap implementations (used in the benchmarks) have been moved to log4j-perf. 

The remaining implementations will be used as follows:
* GarbageFreeSortedArrayThreadContextMap - if the user configured GC-free context map
* CopyOnWriteSortedArrayThreadContextMap - the default for non-web app applications
* DefaultThreadContextMap - the default for web applications (or when Constants.ENABLE_THREADLOCALS
is false)

I'm not sure if it is possible to move ArrayContextData to core since it is used to implement
two of the above context maps. What would be the benefit? Currently the SPI package is self-contained
and doesn't depend on core. That seems like a good thing. Not sure what the problem is...

> Garbage-free ThreadContext map
> ------------------------------
>                 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
>            Assignee: Remko Popma
>             Fix For: 2.7
>         Attachments: DataStructOpsPerfMediumDataSet.png, DataStructOpsPerfSmallDataSet.png,
InjectWithConfigProperties.png, InjectWithoutConfigProperties.png, ThreadContextPut.png, v2_DataStructOpsPerfMediumDataSet.png,
v2_DataStructOpsPerfSmallDataSet.png, v2_InjectWithConfigProperties.png, v2_InjectWithoutConfigProperties.png,
v2_ThreadContextGet.png, v2_ThreadContextPut.png
> 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