harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [Luni][WeakReference]Avoid using strong-referenced objects as keys of WeakHashMap
Date Thu, 29 May 2008 01:55:06 GMT
Can you give some quantitative data?

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.

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


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message