[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
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@116318b,
but then ClassLoaderDomain@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@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@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