3:38 p.m.
Aaron Ogburn created JBCL-185:
---------------------------------
Summary: 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
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
3:46 p.m.
[
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
4:10 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Ales Justin commented on JBCL-185:
----------------------------------
Did you try this on v2.0.11?
* http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/tags/2.0.11.GA/
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
4:39 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn commented on JBCL-185:
-----------------------------------
Could you clarify what you were wondering if I've tried? The performance testing
exposing the issue on 2.0.11.GA? Or implementing this change on 2.0.11.GA? Currently,
neither.
Were you wondering if 2.0.11.GA would already have addressed this? If so, I don't
believe so. Comparing 2.0.11.GA and 2.0.9.GA so far, I'm not really seeing any
notable differences in BaseClassLoader or BaseClassLoaderDomain that would appear to
provide any different caching/locking behavior seen here on 2.0.9.
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
4:52 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Ales Justin commented on JBCL-185:
----------------------------------
Hmm, afais, all valid caches are already in place, before synched code.
result = checkCacheAndBlackList(name, false, trace);
if (result != null)
return result;
If this doesn't return it, then it's not meant to be cached.
Imo, you should check why this doesn't return cached version.
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
5:06 p.m.
[
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
12:20 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn commented on JBCL-185:
-----------------------------------
The reason the class is not cached appears to be the following portion of
BaseClassLoaderDomain.loadClass:
Loader loader = findLoader(classLoader, path, allExports, findInParent);
if (loader != null)
{
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = globalClassCache.get(path);
if (item != null)
item.clazz = result;
return result;
}
The resulting class is only added to a preexisting ClassCacheItem. No ClassCacheItem was
created for this previously on this domain. TRACE logging has shown that the parent
domain is finding the loader in this case and creating initially creating/adding a
ClassCacheItem here instead through findLoaderInExports.
I've attached a test case that I think replicates this issue with a failure to cache
in a child domain. It currently fails but the testcase passes after I implement the
following change to BaseClassLoaderDomain.loadClass that creates and adds a ClassCacheItem
regardless of whether or not an entry already exists:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = new ClassCacheItem(loader);
item.clazz = result;
globalClassCache.put(path, item);
if (trace && item.clazz != null)
log.trace(this + " cached " + name + " in global class cache
");
return result;
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, JBCl-185testcase.tar.gz
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
12:20 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn updated JBCL-185:
------------------------------
Attachment: JBCl-185testcase.tar.gz
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, JBCl-185testcase.tar.gz
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
12:22 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn edited comment on JBCL-185 at 10/1/12 1:20 PM:
------------------------------------------------------------
The reason the class is not cached appears to be the following portion of
BaseClassLoaderDomain.loadClass:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = globalClassCache.get(path);
if (item != null)
item.clazz = result;
return result;
The resulting class is only added to a preexisting ClassCacheItem. No ClassCacheItem was
created for this previously on this domain. TRACE logging has shown that the parent
domain is finding the loader in this case and creating initially creating/adding a
ClassCacheItem here instead through findLoaderInExports.
I've attached a test case that I think replicates this issue with a failure to cache
in a child domain. It currently fails but the testcase passes after I implement the
following change to BaseClassLoaderDomain.loadClass that creates and adds a ClassCacheItem
regardless of whether or not an entry already exists:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = new ClassCacheItem(loader);
item.clazz = result;
globalClassCache.put(path, item);
if (trace && item.clazz != null)
log.trace(this + " cached " + name + " in global class cache
");
return result;
was (Author: aogburn):
The reason the class is not cached appears to be the following portion of
BaseClassLoaderDomain.loadClass:
Loader loader = findLoader(classLoader, path, allExports, findInParent);
if (loader != null)
{
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = globalClassCache.get(path);
if (item != null)
item.clazz = result;
return result;
}
The resulting class is only added to a preexisting ClassCacheItem. No ClassCacheItem was
created for this previously on this domain. TRACE logging has shown that the parent
domain is finding the loader in this case and creating initially creating/adding a
ClassCacheItem here instead through findLoaderInExports.
I've attached a test case that I think replicates this issue with a failure to cache
in a child domain. It currently fails but the testcase passes after I implement the
following change to BaseClassLoaderDomain.loadClass that creates and adds a ClassCacheItem
regardless of whether or not an entry already exists:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = new ClassCacheItem(loader);
item.clazz = result;
globalClassCache.put(path, item);
if (trace && item.clazz != null)
log.trace(this + " cached " + name + " in global class cache
");
return result;
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, JBCl-185testcase.tar.gz
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
12:22 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn edited comment on JBCL-185 at 10/1/12 1:21 PM:
------------------------------------------------------------
The reason the class is not cached appears to be the following portion of
BaseClassLoaderDomain.loadClass:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = globalClassCache.get(path);
if (item != null)
item.clazz = result;
return result;
The resulting class is only added to a preexisting ClassCacheItem. No ClassCacheItem was
created for this previously on this domain. TRACE logging has shown that the parent
domain is finding the loader in this case and initially creating/adding a ClassCacheItem
here through findLoaderInExports instead of the child domain.
I've attached a test case that I think replicates this issue with a failure to cache
in a child domain. It currently fails but the testcase passes after I implement the
following change to BaseClassLoaderDomain.loadClass that creates and adds a ClassCacheItem
regardless of whether or not an entry already exists:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = new ClassCacheItem(loader);
item.clazz = result;
globalClassCache.put(path, item);
if (trace && item.clazz != null)
log.trace(this + " cached " + name + " in global class cache
");
return result;
was (Author: aogburn):
The reason the class is not cached appears to be the following portion of
BaseClassLoaderDomain.loadClass:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = globalClassCache.get(path);
if (item != null)
item.clazz = result;
return result;
The resulting class is only added to a preexisting ClassCacheItem. No ClassCacheItem was
created for this previously on this domain. TRACE logging has shown that the parent
domain is finding the loader in this case and creating initially creating/adding a
ClassCacheItem here instead through findLoaderInExports.
I've attached a test case that I think replicates this issue with a failure to cache
in a child domain. It currently fails but the testcase passes after I implement the
following change to BaseClassLoaderDomain.loadClass that creates and adds a ClassCacheItem
regardless of whether or not an entry already exists:
Thread thread = Thread.currentThread();
ClassLoadingTask task = new ClassLoadingTask(name, classLoader, thread);
ClassLoaderManager.scheduleTask(task, loader, false);
Class<?> result = ClassLoaderManager.process(thread, task);
ClassCacheItem item = new ClassCacheItem(loader);
item.clazz = result;
globalClassCache.put(path, item);
if (trace && item.clazz != null)
log.trace(this + " cached " + name + " in global class cache
");
return result;
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, JBCl-185testcase.tar.gz
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
4:42 p.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Ales Justin updated JBCL-185:
-----------------------------
Fix Version/s: JBossCL.2.0.12.GA
Affects Version/s: JBossCL.2.0.11.GA
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 , JBossCL.2.0.11.GA
Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2
-JBossCL 2.0.9.GA
Reporter: Aaron Ogburn
Assignee: Ales Justin
Fix For: JBossCL.2.0.12.GA
Attachments: BaseClassLoader.java, JBCL-185.patch, JBCl-185testcase.tar.gz
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
10:28 a.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn commented on JBCL-185:
-----------------------------------
Looks like code work is done here and an upgrade to JBCL 2.0.12.GA is now being tracked
for consumption of this fix in EAP 5.2.1 so resolving this jira
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 , JBossCL.2.0.11.GA
Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2
-JBossCL 2.0.9.GA
Reporter: Aaron Ogburn
Assignee: Ales Justin
Fix For: JBossCL.2.0.12.GA
Attachments: BaseClassLoader.java, JBCL-185.patch, JBCl-185testcase.tar.gz
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
10:28 a.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn resolved JBCL-185.
-------------------------------
Resolution: Done
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 , JBossCL.2.0.11.GA
Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2
-JBossCL 2.0.9.GA
Reporter: Aaron Ogburn
Assignee: Ales Justin
Fix For: JBossCL.2.0.12.GA
Attachments: BaseClassLoader.java, JBCL-185.patch, JBCl-185testcase.tar.gz
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
10:30 a.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn closed JBCL-185.
-----------------------------
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 , JBossCL.2.0.11.GA
Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2
-JBossCL 2.0.9.GA
Reporter: Aaron Ogburn
Assignee: Ales Justin
Fix For: JBossCL.2.0.12.GA
Attachments: BaseClassLoader.java, JBCL-185.patch, JBCl-185testcase.tar.gz
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
6:13 a.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Ales Justin commented on JBCL-185:
----------------------------------
I guess you're saying we need to release 2.0.12.GA?
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 , JBossCL.2.0.11.GA
Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2
-JBossCL 2.0.9.GA
Reporter: Aaron Ogburn
Assignee: Ales Justin
Fix For: JBossCL.2.0.12.GA
Attachments: BaseClassLoader.java, JBCL-185.patch, JBCl-185testcase.tar.gz
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
7:57 a.m.
[
https://issues.jboss.org/browse/JBCL-185?page=com.atlassian.jira.plugin.s...
]
Aaron Ogburn commented on JBCL-185:
-----------------------------------
In EAP 5.2.1, we will need to, yeah. That's being tracked through JBPAPP-10220 and
JBPAPP-10221.
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 , JBossCL.2.0.11.GA
Environment: -JBoss Enterprise Application Platform (EAP) 5.1.2
-JBossCL 2.0.9.GA
Reporter: Aaron Ogburn
Assignee: Ales Justin
Fix For: JBossCL.2.0.12.GA
Attachments: BaseClassLoader.java, JBCL-185.patch, JBCl-185testcase.tar.gz
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
5025
days inactive
5054
days old
15 comments
2 participants
participants (2)
-
Aaron Ogburn (JIRA) -
Ales Justin (JIRA)