On 14 June 2013 17:35, Christopher Schultz <ch...@christopherschultz.net> wrote:
> 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 colleague
>>> 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 to
>>> 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.
>>
>> The early Tomcat 7 implementations did it like this - loaded every class
>> and then examined the class object. More recent implementations use BCEL
>> to look at the byte code. It is faster and uses less memory. We also use
>> caching to ensure each class is only processed once.

That functionality sounds like it might be useful as a general purpose
library item, possibly as part of a utility jar for Commons BCEL.
For example JMeter has to scan classes for certain interfaces on
startup. It's current implementation is a bit wasteful.

> Cool. What Classloader gets used to actually load the Class objects,
> though?

BCEL reads class files as files.

http://commons.apache.org/proper/commons-bcel/

> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to