harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: [Luni][WeakReference]Avoid using strong-referenced objects as keys of WeakHashMap
Date Thu, 29 May 2008 11:23:45 GMT

2008/5/29 Nathan Beyer <ndbeyer@apache.org>:
> Can you give some quantitative data?

Hmm, I saw the heap of an application grows much faster than RI in
hours, while RI remain quite small, checking the heap found it's full
of WeakHashMap.Entry, which are handled by java.bean.Introspector.

> It's debatable whether the StandardBeanInfo cache is a memory leak or
> working as designed. The intent seems pretty obvious - cache the
> StandardBeanInfo for a given Class until that Class is no longer used. Is
> the Class still in use? Is Class unloading enabled? Is it working? It's
> hopefully well-known that in-memory caches are a trade-off in memory usage
> for performance. I would suggest that we first discuss whether caching
> StandardBeanInfo is of value, then discuss what's the most appropriate way
> of doing that.

>From the javadoc of Introspector.getBeanInfo() :
"If the BeanInfo class for a Java Bean has been previously
Introspected based on the same arguments then the BeanInfo class is
retrieved from the BeanInfo cache. "
So I think caching of BeanInfo is correct here.

Yes I agree with you, we may discuss the cache design here.

> The ResourceBundle cache seems to be the same case. Again, I'd suggest a
> discussion about that, but in a separate thread.

Agreed, ResourceBundle may be another story.

> -Nathan
> On Wed, May 28, 2008 at 2:47 AM, Jimmy,Jing Lv <firepure@gmail.com> wrote:
>> Hi,
>>    I see a memory leak using Harmony Beans, looking into heap there
>> are many objects of WeakHashMap.Entry, and in hours they were never
>> GCed. And at last I find it was in java.beans.Introspector,  using a
>> WeakHashMap as a cache:
>>    private static Map<Class<?>, StandardBeanInfo> theCache =
>> Collections.synchronizedMap(new WeakHashMap<Class<?>,
>> StandardBeanInfo>(DEFAULT_CAPACITY));
>>    Unfortunately, we see it uses Class objects as WeakHashMap.Entry
>> key, which is always referenced by vm (only can be GCed when a class
>> is unloaded).  but WeakHashMap.Entry extends
>> java.lang.ref.WeakReference, which requires a weak reference as its
>> key, as a result, using Class object shall always keep Entries in
>> heap, cause a memory in that way.
>>    A quick search I also find in java.util.ResourceBundle, it defines
>> its cache as:
>>    private static final WeakHashMap<Object, Hashtable<String,
>> ResourceBundle>> cache = new WeakHashMap<Object, Hashtable<String,
>> ResourceBundle>>();
>>    and in code it uses ClassLoader objects as key.
>>    However as we know, ClassLoader objects are handled by vm as well
>> and may not be released, this as well may cause memory leak.
>>    I suggest if we want to use WeakHashMap(and don't want to cause a
>> memory leak), we may set its key carefully and avoid using objects
>> that are referenced in other area (especially vm) that we can not
>> handle, like Class, etc. And I have a a little approach for String
>> objects, we know they are handled by vm with a pool, so directly use
>> String as key seems  also cause a leak, however if we put it into
>> WeakHashMap as:
>>     WeakHashMap.put(new String(oldString), valueObject);
>>    Run a few minutes I see no leak. Maybe some VM guru can tell us
>> what's going on with the string pool do in VM?
>>    To fix these 2 problem, I suggest create a new inner class and use
>> it as Key of WeakHashMap (don't know if "new String(oldString)" should
>> work? ).
>>    And anyone saw the same problem in Harmony code? Any
>> comments/suggests? Thanks!
>> --
>> Best Regards!
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM


Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

View raw message