[jboss-jira] [JBoss JIRA] (JBCL-185) BaseClassLoader.loadClass() is slow under load

[Aaron Ogburn (JIRA)]

    [ https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722121#comment-12722121 ] 

Aaron Ogburn commented on JBCL-185:
-----------------------------------

Hey Ales,

I had a long email thread on how cached values weren't returned at that point by checkCacheAndBlackList but never got any feedback.  Here is behavior I noted from some extra TRACE logging I had them capture:

-Slow BaseClassLoader.loadClass() calls were checking cache in ClassLoaderDomain at 116318b, but then ClassLoaderDomain at e273fa is used by BaseClassLoader.loadClassFromDomain().  Looks like the domains here are fetched in the same manner though; any ideas why different ones are used at these points?
-Since ClassLoaderDomain at 116318b isn't used for the classloader lookup, the result will never be placed in its global class cache for a quicker return from BaseClassLoader.loadClass().  They're only potentially cached in ClassLoaderDomain at e273fa, which doesn't help performance here.


I CC'd you on that full email if you want to take a look or let me know if you want any of the full trace logging as well.  Any thoughts on the different domains being used there?


Thanks,

Aaron
                
> BaseClassLoader.loadClass() is slow under load
> ----------------------------------------------
>
>                 Key: JBCL-185
>                 URL: https://issues.jboss.org/browse/JBCL-185
>             Project: JBoss ClassLoader
>          Issue Type: Enhancement
>          Components: ClassLoader
>    Affects Versions: JBossCL.2.0.9.GA 
>         Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2
> -JBossCL 2.0.9.GA
>            Reporter: Aaron Ogburn
>            Assignee: Ales Justin
>         Attachments: BaseClassLoader.java, JBCL-185.patch
>
>
> Classloader performance dropped from EAP 4.3 to 5.  Thread dumps show threads facing contention in the classloader:
>    java.lang.Thread.State: BLOCKED (on object monitor)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:495)
> 	- waiting to lock <0x80e22960> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:447)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	at org.jboss.classloading.spi.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:87)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	at org.jboss.util.loading.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:97)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> These are repeat lookups.  The thread and classloader trace logging show that these look ups are not returning cached values from checkCacheAndBlackList() and so they are having to go progress through doLoadClass() and the baseclassloderdomain to finally return the class from another classloaders cache.  This is bad as threads are forced to synchronize to return a cached class from elsewhere whereas the cached value return could all happen concurrently.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira