I thought about a SoftReference Map... But I personally would like to keep a handle on the size of cache instead of having it eat up all my memory and then forcing a garbage collection to remove soft references. My app, for example, has to be FAST, which means pause times for GC activity have to be very low. I use the low-pause collector for that reason. But when I tested with SoftReference Map caches, I found that all my memory was gone and then a huge full GC took place that paused the VM for a considerable length of time. Since then I've not used SoftReference Maps because I'm scared of the memory usage.
On the other hand, finding the right default value for the max cache size is not easy. I'm noticing that a exprCacheSize of 100 is way too small; just one user on my system produces 400 expressions in no time. If the cache were limited to 100 in size by default, my processor would still be maxed out. Naturally the size of the cache would vary from application to application... Would it be possible to have a self-balancing cache? One that would grow to a size where the hit-rate would be steady at about 70%? Then again, the hit-rate would depend upon the variety of expressions being evaluated, which again depends upon how expressions are used in the application. WeakHashMaps won't help us, since the expression Strings are created/destroyed by every tag.... As for more solution ideas, I don't have any right now. I'll give it some more thought. Also, do we want to worry about the fact that users of the standard taglib have to set some magical (i.e. non-obvious) parameter that will make the difference between their system being slow due to re-evaluating expressions or taking up huge amounts of memory? They might not expect such a thing... It would be nicer if it was somewhat self-managing, or at least set to a default value that works for 90% of the users. (Maybe I am not in that 90%...) I don't know if this info helps... You did ask for my "thoughts". :) - Daryl. -----Original Message----- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 1:56 PM To: Tag Libraries Developers List Subject: Re: Memory Leak in ELEvaluator.java (standard v1.0.6) Heh, my reading comprehension skills are failing. JSP 1.2 requires J2SE 1.2 and JSP 2.0 requires J2SE 1.3. Just to clarify Option #2, we're talking about taking the source code for org.apache.commons.collections.map.LRUMap, changing its package, and resolving all its dependencies by doing the same thing with the source code for those classes and interfaces, right? If so, that seems reasonable. It would be nice to be able to script that somehow... In addition to the use of LRUMap, did anyone want to offer an opinion on exposing a mechanism to configure the cache size (setting cache size = 0 would effectively bypass caching)? Personally, I think it's a good idea. In keeping with the mechanics of the Config class, how about defining a servlet context init param? Something like: <context-param> <param-name>org.apache.taglibs.standard.lang.jstl.exprCacheSize</param-n ame> <param-value>100</param-value> </context-param> Any thoughts on using different caching strategies? How about leveraging reference objects (SoftReference might be appropriate)? Quoting Justyna Horwat <[EMAIL PROTECTED]>: > After sending my original mail yesterday I had looked at the JSP 2.0 > requirements and you're right, they don't require J2SE 1.4. > > Out of the options I like Option #2 the best as well for the same > reasons as Daryl and Felipe mentioned. I looked at the Collections > source and they list the JDK dependency as JDK 1.2 or later. > > If support of the Collections classes becomes an issue we can revisit > this decision and always decide to add the jar dependency in the future. > > Unless there are any objections, I'm going to go ahead with Option #2 > and add the Collections LRUMap classes and dependencies into JSTL both > 1.0 and 1.1. > > Thanks, > > Justyna > > Felipe Leme wrote: > > > On Wed, 2004-10-20 at 01:04, Kris Schneider wrote: > > > >>I think I jumped to the conclusion that Daryl was using JSTL 1.1 and > >>hence made the JSP 2.0 -> J2EE 1.4 -> J2SE 1.4 connections. > > > > > > And even JSP 2.0 doesn't require J2SE 1.4, when running inside a > > 'standalone' web-container (i.e, outside a J2EE 1.4 container). > > > > > >>required to support J2SE 1.3. I'm not sure I like taking on the > >>dependency, but the Collections project already contains the classes > > > > > > I thought about the Collections too, but then Standard would be > > compound of 3 jars, which would certainly cause a lot of trouble, as > > people is used to only copying jstl.jar and standard.jar. We have > > alternatives, > > too: > > > > - merge commons-collection.jar into standard.jar > > - replicate the necessary classes into Standard src code > > > > > > > >>org.apache.commons.collections.LRUMap (v.2.1.1) and > >>org.apache.commons.collections.map.LRUMap (v.3.1). I can't seem to put a > >>finger on the J2SE requirements for Collections though... > > > > > > > > Assuming these classes doesn't have deep dependencies on others, I > > would say the second option would be better (in the worst case, we > > would do some minor changes in the classes, like removing calls to > > Commons Logging, if any). > > > > -- Felipe -- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
