Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F0CA7A3.5070000@christopherschultz.net>
Date: Tue, 10 Jan 2012 16:03:31 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: More Caching for WebappClassLoader?
References: <4F0C166B.3010806@kippdata.de>
In-Reply-To: <4F0C166B.3010806@kippdata.de>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig90F195956E25726CB8DE38F7"

--------------enig90F195956E25726CB8DE38F7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Rainer,

On 1/10/12 5:43 AM, Rainer Jung wrote:
> Now loadClass() in the WebappClasLoader does:
>=20
> - check own class cache
> - check super class cache
> - try loading from system loader
> - call Class.forName with parent loader (which calls loadClass() there)=

>   [only if "delegated", which is *not* the default]
> - try loading via findClass()
> - call Class.forName with parent loader (which calls loadClass() there)=

>   [only if not "delegated", which *is* the default]

Hmm.

> What we could do to keep the design simple is caching any positive
> result from loadClass() in the WebappLoader, even it it was found via
> super, system or parent. In addition we could also cache negative
> results for all those. The biggest downsides I can see would be
>=20
> - less dynamics: if someone had a more dynamic loader unerneath ours,
> which would change the result of loadClass() during runtime, we would
> shield the app from it, because we now return classes from our cache.

-0?

Their CL should have the opportunity to load the class first, so it
doesn't matter whether or not we cache the result, right?

> - increased memory use for the cache, i.e. the list of class names and
> references to the classes.

-1

The class names (String) and Class objects will already be in memory
because they will be stored by the "real" ClassLoader that loaded them.
The only thing we will have to do is pay for the additional storage of
those references in our own cache -- so, it's just the cost of the
additional space from our own class mapping table.

> To stay completely compatible I think the feature should not be default=
,
> at least until TC 7, maybe switch default for 8.

This could be implemented as a separate WebappClassLoader, and
configured in the <Context>. That way users can choose, and the default
is the old behavior.

> What do you think? Does it make sense? Should I prepare a patch for tru=
nk?

+1

-chris


--------------enig90F195956E25726CB8DE38F7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8Mp6UACgkQ9CaO5/Lv0PBDeACgg1l4hZDZFKHQISfjBXNetOpi
Q5YAn2t//W9OvPO9rJSVdahNJsoSjnNn
=vken
-----END PGP SIGNATURE-----

--------------enig90F195956E25726CB8DE38F7--