jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justyna Horwat <Justyna.Hor...@Sun.COM>
Subject Re: Memory Leak in ELEvaluator.java (standard v1.0.6)
Date Tue, 19 Oct 2004 21:33:32 GMT
Hi Daryl,

There is actually a bug report already filed:


One possible solution that Kris mentioned is using an LRU cache. We 
could do something as follows in ELEvaluator.java:

final int MAX_ENTRIES = 100;  //*** profiling would help here ***

static Map sCachedExpressionStrings =
     Map cache = new LinkedHashMap (MAX_ENTRIES + 1, .75F, true) {
       public boolean removeEldestEntry(Map.Entry eldest) {
         return size() > MAX_ENTRIES;

I don't have any profilers setup so I'd appreciate your analysis of 
these changes.

I also need to investigate the impact of adding a J2SE 1.4 dependency in 
the codebase. If it's a problem then we may need to do our own 
LinkedHashMap implementation.



Kris Schneider wrote:

> Definitely file a bug in bugzilla. Before a fix gets coded, however, there has
> to be some developer (meaning committer) consensus on what the fix actually is.
> This is the correct forum for the discussion and hopefully the bug report will
> spur additional comments.
> Quoting Daryl Beattie <darylb@date.com>:
>>Okay.... So I'm not used to this; how does the task of fixing this
>>problem get assigned? Should I open a bug in bugzilla for it?
>>I'd gladly work on it and see what I can get done (as long as I can ask
>>you developers for assistance if I need to know how something works).
>>The only question mark in my mind right now is where to put the
>>configuration option, but I'm sure once I start digging through the code
>>I'd find it easily enough.
>>- Daryl.
>>-----Original Message-----
>>From: Kris Schneider [mailto:kris@dotech.com] 
>>Sent: Tuesday, October 19, 2004 2:43 PM
>>To: Tag Libraries Developers List
>>Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
>>Some quick options off the top of my head:
>>J2EE 1.4 requires J2SE 1.4, so we could create an LRU cache with
>>LinkedHashMap (override the removeEldestEntry method).
>>We could also implement a cache using reference objects.
>>Since ELEvaluator already has a constructor arg for bypassing the cache,
>>we could expose a way to configure its use. I think the only place one
>>is currently created is as a singleton within Evaluator. Obviously, this
>>could also be combined with a more memory-friendly cache.
>>Quoting Daryl Beattie <darylb@date.com>:
>>>Hi everyone,
>>>	Following up on the memory leak; I have found that the
>>>memory leak in the ELEvaluator is indeed a real memory leak. Beyond 
>>>profiling to find the bug, I have gone to the trouble of disabling the
>>>sCachedExpressionStrings cache in ELEvaluator, recompiling the 
>>>standard taglib, deploying and re-testing with the cache-disabled jar.
>>>What I found is that indeed the leak did disappear, and after running 
>>>under a load for 8 hours my app was using the same amount of memory as
>>>it had used in the first 20 minutes.
>>>	So it definitely is a leak.
>>>	What should be done about it? Is there a last-recently-used map
>>>we could be using instead of just a regular HashMap? Should I stick 
>>>with my cache-disabled jar?
>>>	I would like to know how you folks would like to handle the bug
>>>that I can eventually get a new version of the standard taglib. 
>>>Otherwise, I'll be stuck deploying my hacked jar and relying on my own
>>>hacked version of the taglib. Let me know if there's any way I can 
>>>help to get this problem fixed; I'd be glad to volunteer some effort 
>>>and even some profiling testing.
>>>	Daryl.
>>>-----Original Message-----
>>>From: Daryl Beattie [mailto:darylb@date.com]
>>>Sent: Friday, October 15, 2004 5:40 PM
>>>To: taglibs-dev@jakarta.apache.org
>>>Subject: Possible Memory Leak in ELEvaluator.java (standard v1.0.6)
>>>Hi everybody,
>>>        I have a question about a possible memory leak in 
>>>ELEvaluator.java. I have noticed when profiling that HashMap entries 
>>>(containing Strings, etc.) are kept by the sCachedExpressionStrings 
>>>static variable and never removed. Over the course of running an 
>>>application for several hours that uses tags that have evaluations in 
>>>them, this Map builds up in memory -- in fact I noticed that it was 
>>>343k for just one tag alone after I ran my app for 5 minutes. I have 
>>>dynamically constructed expressions, and am concerned that each one is
>>>being cached even if that expression is never used again.
>>>        Would it be prudent to use some other kind of Collection to 
>>>store these cached expressions (such as one that times out its entries
>>>after a certain amount of time)?
>>>        Also, I have toyed with the idea of adding functionality to 
>>>permanently disable the cache, but since I do not know the expense of 
>>>creating a new ELParser with the String expression, I do not know if 
>>>this will cripple my system. I believe I have a normal percentage of 
>>>re-used expressions across my tags.
>>>        I also find it interesting that there is functionality to 
>>>bypass getting values from the cache, but there is not yet a way to 
>>>disable its use. Even when bypassing the cache, the cache grows over
>>>        What do you think about this possible leak?
>>>        Daryl.
>>Kris Schneider <mailto:kris@dotech.com>
>>D.O.Tech       <http://www.dotech.com/>

To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org

View raw message