[
https://issues.apache.org/jira/browse/LOG4J2-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909602#comment-16909602
]
Ryan Schmitt commented on LOG4J2-2675:
--------------------------------------
It's a tricky problem. Have you considered special-casing the JDK's generated
classes?
> Performance issue with stack traces containing generated classes
> ----------------------------------------------------------------
>
> Key: LOG4J2-2675
> URL: https://issues.apache.org/jira/browse/LOG4J2-2675
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.12.1
> Reporter: Ryan Schmitt
> Priority: Major
>
> We've noticed a performance problem with stack traces that contain certain
> types of generated classes. For example:
> {noformat}
> 16 Aug 2019 15:54:33,470 [INFO] (main) com.example.LoggingIntegrationTest:
> Exception thrown
> java.lang.reflect.InvocationTargetException: null
> at
> jdk.internal.reflect.GeneratedConstructorAccessor10.newInstance(Unknown
> Source) ~[?:?]
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> ~[?:?]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> ~[?:?]
> at
> com.example.LoggingIntegrationTest.construct(LoggingIntegrationTest.java:25)
> ~[classes/:?]
> {noformat}
> In this example, {{jdk.internal.reflect.GeneratedConstructorAccessor10}} is a
> class generated by the JDK in order to optimize the reflective
> {{Constructor#newInstance}} call. One quirk of these classes (called
> "inflated constructors" within the JDK) is that [they get loaded in their
> very own
> classloader|https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/sun/reflect/ClassDefiner.java#L39-L65].
> Since Log4j2 has no hope of finding this classloader, it also cannot
> [resolve the class name to a Class
> object|https://github.com/apache/logging-log4j2/blob/de6593f5f3b5acbb2cdb4ee91e4e1f472db5dcbb/log4j-core/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxyHelper.java#L197-L233]
> in {{ThrowableProxyHelper#loadClass}}. This means that every stack trace
> containing such a class, when it is rendered, will cause the entire classpath
> to be scanned.
> It seems that {{ThrowableProxyHelper}} should have some sort of negative
> caching in order to optimize this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
