[jboss-dev-forums] [Design of POJO Server] - Re: Caching of classes in BaseClassLoaderDomain

[adrian@jboss.org]

"bstansberry at jboss.com" wrote : 
  | EAP 4.3
  | 
  | a single get from a concurrent hash map:
  | 
  | return UnifiedLoaderRepository3.classes.get(name);
  | 
  | AS 5.x
  | 
  | 1) Ask the parent for the class, which calls ClassLoader.loadClass() proceeding all the way to the bootstrap classloader, executing privileged blocks throwing CNFEs wrapped inside PrivilegedActionExceptions  at each level and then catching and discarding them. The above stack trace catches a thread in the middle of creating a PrivilegedActionException.
  | 2) Executing BaseClassLoaderDomain.findLoader logic to find the Loader that loaded the class.
  | 3) Scheduling and processing ClassLoadingTask to get the class from the Loader.
  | 
  | Yikes! If the 4.x approach is too much of a "big ball of mud" can't we at least find a way to skip step #1 if the class was already loaded from one of the loaders associated with the domain?
  | 

Yes, I agree. There already is a "globalClassCache" when it emulates the
"big ball of mud", but the processing of this is inefficient as you mention
i.e. it caches the Loader not the Class and goes through the task scheduling inside the
classloader lock.

I'll change the checking of the cache to be more like JBoss4.x 
although the actual population of the cache needs to remain similar to what it now
since even the "big ball of mud" can be tweeked such as turning off caching
for individual classloaders or choosing not to export everything.
https://jira.jboss.org/jira/browse/JBCL-100

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226986#4226986

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226986