Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
MIME-Version: 1.0
In-Reply-To: <56165846.8060407@apache.org>
References: 
 <CAKgEu6cBwztrc1hufY-GqLkduyQ=M1NVXNhxZHahyV=b=srxoQ@mail.gmail.com>
	<56165846.8060407@apache.org>
Date: Thu, 8 Oct 2015 15:24:06 +0200
Message-ID: 
 <CAKgEu6cg-=UJEXi-tk-LDP=6w2zbH+F6WELFNmbO6Y0KcGZsow@mail.gmail.com>
Subject: Re: Another attempt at discussing the major performance issue in
 Tomcat 8 JSP
From: sebdotv <sebdotv@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=UTF-8

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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org