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
possible.
- 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 :)
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
