Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: error (nike.apache.org: local policy)
Message-ID: <51BB4636.5080706@christopherschultz.net>
Date: Fri, 14 Jun 2013 12:35:02 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Jar scanning, SCI scanning, fragment scanning
References: <51B9F21E.9070504@apache.org>
 <51BA8093.1000900@christopherschultz.net> <51BAC33A.7010406@apache.org>
 <51BB3D5F.3070308@christopherschultz.net> <51BB4303.60805@apache.org>
In-Reply-To: <51BB4303.60805@apache.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="----enig2WLHHLMDGIIDNXVWGCSVH"

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

Mark,

On 6/14/13 12:21 PM, Mark Thomas wrote:
> On 14/06/2013 16:57, Christopher Schultz wrote:
>> Mark,
>>
>> On 6/14/13 3:16 AM, Mark Thomas wrote:
>>> On 14/06/2013 03:31, Christopher Schultz wrote:
>>>
>>>> It might be nice if this were not a one-of-many decision, but if a
>>>> client could choose more than one type. A bit-mask or a list of
>>>> scan-types would be nice. I could see the same type of scanner being=

>>>> used for multiple different purposes.
>>>
>>> That is what ServletContainerIniiializers are for.
>>
>> Well, crap. I had never seen those before.
>>
>> I'm curious, though. Thinking about this the other day with a colleagu=
e
>> who was complaining about some kind of Spring configuration that
>> evidently loaded every class available on the classpath and kept them =
in
>> memory (thus leading to heap and PermGen issues), I concluded that the=

>> only sane way to do this kind of probing would be to probe everything =
in
>> a ClassLoader that was intended to be discarded after the probing as t=
o
>> avoid loading classes unnecessarily.
>>
>> If an SCI retains a reference to any of the Class objects in the
>> Set<Class> parameter, that hypothetical throw-away ClassLoader is no
>> longer thrown-away.
>=20
> The early Tomcat 7 implementations did it like this - loaded every clas=
s
> and then examined the class object. More recent implementations use BCE=
L
> to look at the byte code. It is faster and uses less memory. We also us=
e
> caching to ensure each class is only processed once.

Cool. What Classloader gets used to actually load the Class objects,
though? In the pathological case of @HandlesType('java.lang.Object')
that means everything gets loaded into .. the WebappClassLoader?

One could imagine a case where an SCI wants to look at everything, but
then only ends up caring about 2% of what's been loaded. Is that just
the price you have to pay for inspecting everything -- that you
seriously waste PermGen? (at least for current Oracle JVMs)

-chris


------enig2WLHHLMDGIIDNXVWGCSVH
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 Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRu0Y2AAoJEBzwKT+lPKRYrCgP/RgMHgqFrJ8MFnV+8nolzLfk
hucJmWILyGjBiq+/b2HAMEgrclejMPLy7MNStpOogrXxF5aOkfmnsOjTrQlM9sbi
K0sBso79ddB8CKqXsQkYbVD/YQSXlkhlo3UrYvK6/rucpDfWg+XlvPaORP49sFdU
+yydl718DCcoLhZBQMeNBrrIEUVY+7xxPfqk2jClUfBVcvRB75rAwqECGCEQ3UY3
3ONGFBwIX+QqZ5bbZqNM0ST+qh+v0y9up2FtKu1urwDvpPagb/WWALVIvBqzWj5V
UkJ/fUKRBWEFk4Hf+QP1nqZzlGtP37TLPw9Sk5CAIN9kyuQaoByspTO24s74ueDW
k5vxQMT18ief+fYHbnCZM068MubBWdRPUF38TXef5daeTWPmans63olFxaoNtX24
3T+62f+FBbcAicfhqeaeSF78iUAT2c7GzDcJHIq/lrOkzN5Avfy4F+Hzi4sjjdem
z9TlmAeT3zKcDY8jiohb7FNv6P3LSNcS07ZWiGF3iP5THLxIHHt8dS7n2FKnrWwV
b5U+AEDp9/B/ILXaDrrhggcgk5wojYCVF71jDXZwG71Wb5+XwKjO78ioda1k+hgQ
+Qt1E1DkpSGPdBA7KzOXd6Zim2GGj47V/zqSlYmpYZ4UxWKyzFRzZOQCLtHYGeAm
Qw6782RbGgxWTxqQpQFt
=VsSs
-----END PGP SIGNATURE-----

------enig2WLHHLMDGIIDNXVWGCSVH--