https://issues.apache.org/bugzilla/show_bug.cgi?id=56838
--- Comment #6 from Mark Thomas <ma...@apache.org> --- (In reply to Konstantin Kolinko from comment #5) > (In reply to Mark Thomas from comment #3) > > The bulk of the performance difference between 7.0.x > > and 8.0.x is as a result of different optimisations (e.g. r1539992 ) being > > applied to 8.0.x when compared to 7.0.x. > > Regarding r1539992 > In case if we are trying to load a class that is already loaded by the > "system" classloader (it is called "javaseLoader" in the current trunk code). > > In the old code the system.loadClass() call does system.findLoadedClass() as > one of its first steps and will return fast. In the new code it does > getResource() lookup which is slower. But the new code doesn't trigger a CNFE. Generation of that exception is really slow. > a) Is r1539992 really worth it? I expect that a typical web application and > its libraries do load a lot of classes from the system classloader. The benefit (or cost) will vary from app to app but those CNFE were really killing the start time of medium to large apps. > b) Implement a cache that lists classes that have been already loaded by > system class loader? I thought about that. If an app tries to load 1000 difference classes from the system class loader the cache wouldn't help and woudl actually make things worse. If an app tries to load the same class 1000 times from the system class loader then a cache would help. The cache solution penalises what looks like (to me) sensible behaviour and rewards what looks like (to me) non-sensible behaviour. That didn't seem right to me. We can't call findLoadedClass(String) since that is a protected method. Unless... One option to speed things up would be to use reflection to make findLoadedClass(String) accessible and then call it directly. That would give the benefits of r1539992 without and additional costs. I'll take a look... -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
