[
https://issues.apache.org/jira/browse/JEXL-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-61:
------------------------------
Fix Version/s: (was: Later)
2.0
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 classes).
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: https://issues.apache.org/jira/browse/JEXL-61
> 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
> removed.
> 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.
