tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: More Caching for WebappClassLoader?
Date Tue, 10 Jan 2012 22:37:59 GMT
Hi Chris,

On 10.01.2012 22:03, Christopher Schultz wrote:
> Rainer,
> On 1/10/12 5:43 AM, Rainer Jung wrote:
>> Now loadClass() in the WebappClasLoader does:
>> - check own class cache
>> - check super class cache
>> - try loading from system loader
>> - call Class.forName with parent loader (which calls loadClass() there)
>>    [only if "delegated", which is *not* the default]
>> - try loading via findClass()
>> - call Class.forName with parent loader (which calls loadClass() there)
>>    [only if not "delegated", which *is* the default]
> Hmm.
>> What we could do to keep the design simple is caching any positive
>> result from loadClass() in the WebappLoader, even it it was found via
>> super, system or parent. In addition we could also cache negative
>> results for all those. The biggest downsides I can see would be
>> - less dynamics: if someone had a more dynamic loader unerneath ours,
>> which would change the result of loadClass() during runtime, we would
>> shield the app from it, because we now return classes from our cache.
> -0?
> Their CL should have the opportunity to load the class first, so it
> doesn't matter whether or not we cache the result, right?

It would matter if they take the reedom to return something new if 
loadClass() is called for a class that was already loaded - and 
something changed for the CL. For example a custom CL could check every 
now and then whether the classes have dynamically changed and then 
return the new ones. If we cache the first result of loadClass() in our 
loader higher up the hierarchy, the custom CL lower down will never be 
called again for the class and wouldn't be able to update it. Sure 
that's not a common feature of class loading, but it would be good to 
keep the caching optional in order to to make such a dynamics feature 

>> - increased memory use for the cache, i.e. the list of class names and
>> references to the classes.
> -1
> The class names (String) and Class objects will already be in memory
> because they will be stored by the "real" ClassLoader that loaded them.
> The only thing we will have to do is pay for the additional storage of
> those references in our own cache -- so, it's just the cost of the
> additional space from our own class mapping table.

Right, tahT#s what I wanted to say. So at the end it might be a few 
thousands of pointers.

>> To stay completely compatible I think the feature should not be default,
>> at least until TC 7, maybe switch default for 8.
> This could be implemented as a separate WebappClassLoader, and
> configured in the<Context>. That way users can choose, and the default
> is the old behavior.
>> What do you think? Does it make sense? Should I prepare a patch for trunk?
> +1

Thanks, to Mark as well for his comments :)



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message