[
https://issues.apache.org/jira/browse/LOG4J2-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742559#comment-16742559
]
ASF subversion and git services commented on LOG4J2-2533:
---------------------------------------------------------
Commit 63731ca8d441af3820b2ed8a5909dd251cbae080 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=63731ca ]
Adapt the fix for LOG4J2-2533 (github #251) for java 7
> Garbage creation introduced by LOG4J2-2301
> ------------------------------------------
>
> Key: LOG4J2-2533
> URL: https://issues.apache.org/jira/browse/LOG4J2-2533
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.11.1
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
> Fix For: 3.0.0, 2.11.2
>
>
> Reported here: [https://github.com/apache/logging-log4j2/pull/251]
> {noformat}
> Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)
> java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal, Object) line: 481 10
> 3,638,864 56.192
> java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal$ThreadLocalMap,
> ThreadLocal, Object) line: 298 10 3,638,864 56.192
> java.lang.ThreadLocal.setInitialValue() line: 184 10 3,638,864 56.192
> java.lang.ThreadLocal.get() line: 170 10 3,638,864 56.192
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.log(LogEvent,
> LoggerConfig$LoggerConfigPredicate) line: 91 10 3,638,864 56.192{noformat}
> We clear and re-set a threadlocal value, which plays with the internal
> thread-map size like an accordion, increasing probability unused thread
> entries will be removed. By setting back to a default value rather than
> clearing the threadlocal we can avoid allocation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
