[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn updated JBCL-185:
------------------------------
Attachment: JBCL-185.patch
BaseClassLoader.java
We have a customer facing this issue currently in a migration effort. I whipped up a
potential fix for them to test that would allow them to cache locally to the BCL to return
from BCL.loadClass() calls before trying to go through synchronization and the domain.
They confirmed this change resolved the performance degradation experienced moving from
4.3 to 5. Attached is the diff file and source file encompassing my changes for this on
2.0.9.GAs BCL.
Would anyone more well versed mind reviewing these changes? Can we implement these in the
JBoss Classloader?
Or would there be a better way to get these loadClass calls to return from cache before
synchronizing and bottlenecking?
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