You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Matt Sicker (JIRA)" <ji...@apache.org> on 2016/03/08 22:17:40 UTC
[jira] [Commented] (LOG4J2-869) Monitor contention at
org.apache.logging.log4j.core.util.Loader.*
[ https://issues.apache.org/jira/browse/LOG4J2-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185818#comment-15185818 ]
Matt Sicker commented on LOG4J2-869:
------------------------------------
ClassLoader.loadClass() also uses a lock, though since 1.7 this supports using a single lock per class name it looks like. Is this still a problem in 2.5 with Java 1.7+?
> Monitor contention at org.apache.logging.log4j.core.util.Loader.*
> -----------------------------------------------------------------
>
> Key: LOG4J2-869
> URL: https://issues.apache.org/jira/browse/LOG4J2-869
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0.1, 2.0.2, 2.1
> Reporter: Lucas Pouzac
> Labels: concurrency, performance
> Attachments: monitor_contention_log4j.png
>
>
> Loader.initializeClass() / Loader.loadClass() indirectly calls Class.forName0(), which calls into JRE lib method causing monitor contention. See screen shot
> Fix by caching values returned by Class.forName() in a static ConcurrentMap
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org