tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Holle, Jess" <>
Subject RE: StandardClassLoader ?
Date Thu, 05 Aug 2004 18:55:35 GMT
This is actually a very important feature of WCL: the ability to remember class and resource
"misses" against jars and not bother searching for what cannot possibly be there.

I can see that Sun did not feel this was UCL's job, but I've seen things suffer dearly from
the lack of this functionality.

Jess Holle

-----Original Message-----
From:	Filip Hanik - Dev []
Sent:	Thu 8/5/2004 1:37 PM
To:	Tomcat Developers List
Subject:	Re: StandardClassLoader ?
here is the huge performance boost:

Every single time I deserialized an object, it has to do a cl.loadClass(),
now using a custom object stream, it would search the WCL first, then the SCL. And since it
didn't exist in WCL, it still seemed to
do a long scan each time, and then defaulting back to SCL at which point it was fast.

By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe
told me, I trust him :)
Is this scenario clear?

----- Original Message -----
From: "Remy Maucherat" <>
To: "Tomcat Developers List" <>
Sent: Thursday, August 05, 2004 11:01 AM
Subject: Re: StandardClassLoader ?

Filip Hanik - Dev wrote:

>During session replication I optimized my code to decide what order class loader to use
based on the class name.
>For example, if you load a class that starts with org.apache.catalina. I attempt to load
it with the SCL first, it gave the app a
>huge performance boost.
>I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts
you can make, like make a list of all the
>classes in common/lib and server/lib and never load those through WebCL unless specified
by the user. Most user would love the
>performance gain of this, and the ability to turn it on/off
This is extremely easy to test: you need to add stuff to the package
array in WCL, so that it will delegate for these packages. This doesn't
improve performance in any noticeable way (as I expected), so I don't
see where you found any huge performance boost. While it does sound
great, I think your test seemed either bad or very specific.

 From my profile, the bottleneck for the startup time is XML parsing and
accessing entries in JARs (we can't do anything about that), with a
little for classloading as well (but it's not very big, and my
optimization plans were to experiment loading everything at once on
stratup, to be able to remove all syncing in the CL - I don't even know
if that would have been efficient, and since it does conflict with the
more interesting stuff from Costin, I'm giving up on that one for now).


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

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

View raw message