Re: [Springframework-developer] CachedIntrospectionResults

[Guillaume P. <gpo...@gl...>]

Claudio,

I'm not completely sure to understand correctly your question, but I 
will try to answer as best as I can.

WeakHashMap is implemented with WeakReference for keys, and strong 
reference for values.  That means if the value has a strong reference on 
the key, then the key cannot be garbage collected until the WeakHashMap 
is ready for collection.  However, if the value has no strong reference 
on its key, then being in the WeakHashMap won't prevent the key and 
value from being garbage collected if it is otherwise ready.  The 
WeakHashMap knows when to remove the key (and the value with it) by 
using the notification provided by the java.lang.ref package.  For more 
information on this, see: 
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html

So the problem here with the CachedIntrospectionResults is that it uses 
BeanInfo and PropertyDescriptor that both have strong reference to the 
class (indirectly by a reference on Methods of the class).  That will be 
solved with JDK 1.5 that uses a combinaison of Weak and Soft Reference 
to the Class and Method objects, but for 1.4.2, there's not really any 
better solution than to flush the Introspector's cache and/or use 
WeakReference on CachedIntrospectionResults. Using WeakReference on the 
CachedIntrospectionResults is safer, but decrease performance, and in 
such case a manual Instrospector.flushFromCaches(Class) must be used, so 
that the Instrospector does not keep a strong reference on the BeanInfo.

When a webapp is hot-redeployed, a new ClassLoader is created to load 
the webapp, and the old one is thrown away, expected to be garbage 
collected.  For the collection to happen, the server must clear any 
strong reference to the ClassLoader or its classes, and also the webapp 
must make sure that any code in parent ClassLoaders (or siblings) clear 
any reference it might have to any of the webapp's class.

Hopefully this answers your question, but if it does not (or if it's not 
clear enough), please give me more details of what information you need.

Regards,
Guillaume


Claudio D'Angelo wrote:

> Thank's Guillaume.
> I'm studing about the WeakHashMap and I've seen that WeakHashMap build 
> a weak reference on the key (it's right??), when the key hasn't any 
> reference the entity is removed by map.
>
> Spring use a class type to save the key. When the class object haven't 
> any reference? When the Classloader is shutdown?
>
> Can you explain to me (or advise to me if exists an article or 
> tutorial) about?
>
> Thanks,
>  Claudio
>
>
> At 10.05 15/07/2004 -0400, you wrote:
>
>> As Juergen pointed out, if you find a static member hasn't been 
>> garbage collected, it just means its ClassLoader cannot be garbage 
>> collected yet, the static member is not necessarly at fault there.  
>> For an explanation of the current behavior, see below.
>>
>> For the solution, you can use a ServletContextListener to call 
>> java.beans.Introspector.flushCaches() when the ServletContext is 
>> detroy (which causes the ClassLoader to be thrown away).
>>
>>>                 if (results == null) {
>>>                         // can throw BeansException
>>>                         results = new CachedIntrospectionResults(clazz);
>>>                         boolean cacheSafe = isCacheSafe(clazz);
>>>                         if (logger.isDebugEnabled()) {
>>>                                 logger.debug("Class [" + 
>>> clazz.getName() + "] is " + (!cacheSafe ? "not " : "") + "cache-safe");
>>>                         }
>>> *                        classCache.put(clazz, new 
>>> WeakReference(results));
>>> *                }
>>
>> Since Spring 1.0.2, the current code of this method is the following :
>>
>>         if (results == null) {
>>             // can throw BeansException
>>             results = new CachedIntrospectionResults(clazz);
>>             boolean cacheSafe = isCacheSafe(clazz);
>>             if (logger.isDebugEnabled()) {
>>                 logger.debug("Class [" + clazz.getName() + "] is " + 
>> (!cacheSafe ? "not " : "") + "cache-safe");
>>             }
>>             if (cacheSafe) {
>>                 classCache.put(clazz, results);
>>             }
>>             else {
>>                 classCache.put(clazz, new WeakReference(results));
>>             }
>>         }
>>
>> What the isCacheSafe(Class) method does is check if the clazz's 
>> ClassLoader is the
>> same as CachedIntrospectionResults, or a parent of it.  Because what 
>> prevent garbage
>> collection of a ClassLoader A is if a class of a ClassLoader B that 
>> is not for garbage
>> collection has a reference on a class (or instance) of the 
>> ClassLoader A.  However, if
>> A is a parent of B (or B == A), then A cannot be collected anyway.  
>> Which is why if clazz
>> is considered "cacheSafe", no WeakReference is necessary, and in such 
>> case it improve
>> performance.  For example, if the class introspected is a JDK class, 
>> or a Spring class, its
>> ClassLoader can never be collected before the 
>> CachedIntrospectionResults class.
>>
>>> I don't understand about memory leak, weark or soft referance but 
>>> I've see that CachedIntrospectionResults is referenced by  
>>> CachedIntrospectionResults.classCache and there are 2 instances 
>>> (org.springframework.context.support.ResourceBundleMessageSource and 
>>> org.springframework.web.servlet.DispatcherServlet)
>>
>> I don't know what causes the ClassLoader to be retained, but you 
>> cannot easily know what is the cause, just knowning that singletons 
>> instances are still in the JVM only proves that the ClassLoader has 
>> not been garbage collected.  The problem is that something in a 
>> parent (or sibling) ClassLoader still has a reference on a Class of 
>> your webapp's ClassLoader.  The trick is to find what is.
>>
>> Guillaume
>>
>> Claudio D'Angelo wrote:
>>
>>> I've deployed the minimal application (see the spring's sample). 
>>> There isn't Quarts, ibatis or hibernate. There is a controller with 
>>> a test.jsp only.
>>>
>>> I don't understand about memory leak, weark or soft referance but 
>>> I've see that CachedIntrospectionResults is referenced by  
>>> CachedIntrospectionResults.classCache and there are 2 instances 
>>> (org.springframework.context.support.ResourceBundleMessageSource and 
>>> org.springframework.web.servlet.DispatcherServlet)
>>>
>>>
>>> Where I can call the java.beans.Introspector.flushCaches()?
>>>
>>> Please help. After 20 redeploy Tomcat goes in OutOfMemory and ELS 
>>> craches
>>>
>>> At 15.17 15/07/2004 +0200, you wrote:
>>>
>>>> If this happens with Spring 1.0.2, it is typically caused by 
>>>> *other* code that causes a leak. The ClassLoader is then still 
>>>> around, also showing Spring classes like 
>>>> CachedIntrospectionResults. This is not Spring's fault: Spring 
>>>> classes just keep hanging around as a side effect.
>>>>  
>>>> Try calling "java.beans.Introspector.flushCaches()" on application 
>>>> shutdown. This is a typical source of such leaks: The JavaBeans 
>>>> Introspector might still refer to application classes. This is not 
>>>> caused by Spring: It's rather other libraries that use the 
>>>> Introspector, for example Quartz.
>>>>  
>>>> Juergen
>>>>  
>>>>
>>>> ________________________________
>>>>
>>>> Von: spr...@li... 
>>>> <mailto:spr...@li...> im 
>>>> Auftrag von Rod Johnson
>>>> Gesendet: Do 15.07.2004 14:38
>>>> An: spr...@li... 
>>>> <mailto:spr...@li...>
>>>> Betreff: Re: [Springframework-developer] CachedIntrospectionResults 
>>>> classCache leak
>>>>
>>>>
>>>>
>>>> Claudio
>>>>
>>>> What version of Spring is your analysis against?
>>>>
>>>> R
>>>>
>>>> ----- Original Message -----
>>>> From: "Claudio D'Angelo" <cla...@ob...> 
>>>> <mailto:cla...@ob...>
>>>> To: <spr...@li...> 
>>>> <mailto:spr...@li...>
>>>> Sent: Thursday, July 15, 2004 10:26 AM
>>>> Subject: [Springframework-developer] CachedIntrospectionResults 
>>>> classCache
>>>> leak
>>>>
>>>>
>>>> > Hi,
>>>> > I'm analyzing with OptimizeIt my web application:
>>>> > when I redeploy the application I note that instances of
>>>> > CachedIntrospectionResults still in memory and for any redeploy the
>>>> > instances raise.
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>> FREE Java Enterprise J2EE developer tools!
>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click 
>>>> <http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click>
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li... 
>>>> <mailto:Spr...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>> FREE Java Enterprise J2EE developer tools!
>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li... 
>>>> <mailto:Spr...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>>>
>>>
>>> Grazie e buon lavoro
>>> ------------------------------------------------------------------------
>>> *Claudio D'Angelo
>>> *Software Consultant
>>> *ObjectWay S.p.A.
>>> *Via G.A. Boltraffio 7
>>> 20159 Milano (MI)
>>> *http://www.objectway.it <http://www.objectway.it/>
>>>
>>> *
>>> -- 
>>> La presente comunicazione potrebbe contenere informazioni riservate 
>>> e/o protette
>>> da segreto professionale ed e' indirizzata esclusivamente ai 
>>> destinatari della
>>> medesima qui indicati. Se avete ricevuto per errore la presente 
>>> comunicazione,
>>> siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo 
>>> di e-mail,
>>> e a cancellare il presente messaggio dal Vostro sistema. E' 
>>> strettamente proibito
>>> e potrebbe essere fonte di violazione di legge qualsiasi uso, 
>>> comunicazione, copia
>>> o diffusione dei contenuti di questa comunicazione da parte di chi 
>>> la abbia
>>> ricevuta per errore o in violazione degli scopi della presente.
>>> Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>>> pericolosi ed
>>> e' risultato NON infetto. 
>>
> Grazie e buon lavoro
> ------------------------------------------------------------------------
> *Claudio D'Angelo
> *Software Consultant
> *ObjectWay S.p.A.
> *Via G.A. Boltraffio 7
> 20159 Milano (MI)
> *http://www.objectway.it <http://www.objectway.it/>
>
> *
> -- 
> La presente comunicazione potrebbe contenere informazioni riservate 
> e/o protette
> da segreto professionale ed e' indirizzata esclusivamente ai 
> destinatari della
> medesima qui indicati. Se avete ricevuto per errore la presente 
> comunicazione,
> siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo 
> di e-mail,
> e a cancellare il presente messaggio dal Vostro sistema. E' 
> strettamente proibito
> e potrebbe essere fonte di violazione di legge qualsiasi uso, 
> comunicazione, copia
> o diffusione dei contenuti di questa comunicazione da parte di chi la 
> abbia
> ricevuta per errore o in violazione degli scopi della presente.
> Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
> pericolosi ed
> e' risultato NON infetto.
>