tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebdotv <>
Subject Re: Another attempt at discussing the major performance issue in Tomcat 8 JSP
Date Thu, 08 Oct 2015 13:24:06 GMT
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

> 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?


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

View raw message