Mark, thanks for your quick and detailed answer. > Hmm. With 9.0.x trunk there are 4 calls, not 12 to loadClass. One (not > three) for each package. I can't immediately think of any reason why > 8.0.x would make additional calls. Having checked, it doesn't. 8.0.x > makes 4 calls just like 9.0.x. I don't see anything that would have > changed this since 8.0.27.
You're right, I was counting recursive calls in the classloader. 1 call is indeed made per package, so here 4 calls per undefined attribute. > Regardless of whether there are 4 or 12 calls, I agree the performance > impact is going to be significant. The time is mostly spent constructing > the ClassNotFoundException. Annoyingly, this is then thrown away. As set > out in [1], there is a work-around but that comes with its own > performance impact and it is currently the view that we don't want to > slow down valid lookups to make invalid lookups faster. Not that it matters much at this point, but I am not seeing so much of the time constructing the exception. A good part of the time is spent blocking on WebappClassLoader, unless ParallelWebappClassLoader is used. Then the loading of a class means searching for it everywhere on the classpath, which takes time (IO). Of course classloaders should not be used in vain, especially not repeatedly. > > - if everything is conform with the spec, a more aggressive cache should > > probably be implemented and used by ImportHandler > > That is a lot easier said than done. > - A new ImportHandler instance is required for every page request > - Each page can have a different set of imports > - ImportHandler is spec class used by multiple web applications each of > which will have a different set of classes available > - The cache needs to be thread safe > - The cache needs to be self-limiting in size Not knowing anything about the internals of Tomcat, but what about something like a concurrent hashmap with weak keys (classloader + name) and values (class), used in ImportHandler.findClass? Do you foresee issues with something along these lines? Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
