commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Biestro (JIRA)" <>
Subject [jira] Updated: (JEXL-61) Usage of strong references on Method/Constructor & WeakHashMap usage
Date Mon, 09 Nov 2009 21:57:32 GMT


Henri Biestro updated JEXL-61:

    Fix Version/s:     (was: Later)

After review & test, the current code holding strong references to method forbids the
GC to reclaim any class JEXL introspected. The fix to come will use SoftReference to wrap
all caches used by JEXL (JexlEngine & UnifiedJEXL expression caches, IntrospectorBase
caches); this will allow JEXL to release everything it holds under memory pressure (including
Since caches can be rebuilt, no feature is lost; using SoftReference make those caches resilient
if memory pressure is low.
I believe this is a good compromise.

> Usage of strong references on Method/Constructor & WeakHashMap usage
> --------------------------------------------------------------------
>                 Key: JEXL-61
>                 URL:
>             Project: Commons JEXL
>          Issue Type: Improvement
>    Affects Versions: 2.0, 1.1.1
>            Reporter: Henri Biestro
>            Assignee: Henri Biestro
>             Fix For: 2.0
> In MethodMap and IntrospectorBase in 2.0, we are using strong references on Method(s)
and Constructor(s).
> However, the ClassMap is using a WeakHashMap keyed on class and IntrospectorBase use
SoftRefence on classes to allow the GC to remove them if the need arise.
> I might misunderstand the whole thing but it seems "odd" since the GC can probaby *not*
remove a class for which a strong reference on method or constructor exists; the getDeclaringClass
seems to prevent this from being possible. The fix would be to use SoftReference on those
List<Method> and Constructor used in the code.
> The second - nitpicking - oddity is that a WeakHashMap is not the best fit for the kind
of cache Jexl is using; a "SoftHashMap" should be a better choice; but the previous fix could
prevent the inherent WeakHashMap problem too since holding those methods/ctors through SoftReference
should still make "hard enough" references to the classes held by the keys for them to be
> In any case, the code is this way since its origin and no-one has complained (yet) about
this (obscure feature to me) which documented intent is to "detect class loader changes".,
thus the low priority. My (wild)guess is that anyone having really encountered this issue
probably increased permSpace size for other reasons.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message