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

Ralph Goers edited comment on LOG4J2-1349 at 6/25/16 4:25 PM:
--------------------------------------------------------------

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.

I should add though, that while I am not a fan of modifying the ThreadContext 
API, I don't really mind if the LogEvent is modified to use some other data 
structure to contain the ThreadContext and other properties the user may want 
to provide.


was (Author: ralph.go...@dslextreme.com):
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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to