[ 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