[
https://issues.apache.org/jira/browse/LOG4J2-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15349702#comment-15349702
]
Ralph Goers commented on LOG4J2-1349:
-------------------------------------
I am wondering if we are taking this too far. While reducing the amount of
garbage we create is a good thing, I am not sure going to great lengths to make
everything garbage free is. We have introduced extra complexity and your own
tests that gc-free sometimes results in worse performance. I am not sure that
in those cases being gc-free is really worth it.
As for your proposal here, the LogEvent is supposed to be immutable, at least
for the components that can access it. We do not want Appenders and Filters to
modify it without making a copy to pass along to their descendants. Otherwise
other Appenders and Filters that receive the LogEvent will get a LogEvent that
is different than what was logged.
So before doing anything I would like to understand if this is really going to
improve performance in any way.
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
