[jboss-jira] [JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8

[James Perkins (Jira)]

    [ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976789#comment-13976789 ] 

James Perkins commented on LOGMGR-263:
--------------------------------------

Thank you for the analysis [~papegaaij]. That is an interesting workaround for sure. I'll have to look at some workarounds for this or possibly a way to disable the class walker and use the old approach.

The main reason for requiring this is looking for class loaders on the call stack that have a specific log context configuration. A class loader could be registered for a deployment if there is a {{logging-profile}} being used or the deployment contains a logging configuration. One approach might be in WildFly itself to not walk the stack if no logging profiles are defined or no deployments contain logging configuration files.

> Logger Lookup is much slower as with JDK 8
> ------------------------------------------
>
>                 Key: LOGMGR-263
>                 URL: https://issues.redhat.com/browse/LOGMGR-263
>             Project: JBoss Log Manager
>          Issue Type: Bug
>         Environment: WildFly 17, OpenJDK 11
>            Reporter: Andreas Liebscher
>            Priority: Major
>         Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, responsetimes.png
>
>
> During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword.
> Please check the VisualVM output as prove of JDKSpecific got slower:



--
This message was sent by Atlassian Jira
(v7.13.8#713008)