Of course it helps. By the way, you wouldn't have to *only* use soft references.
I dimly recall implementing a cache that combined the use of strong references
for the entries that *had* to be in the cache (according to some strategy) and
using soft references for other entries. I suppose you could also define an
upper bound on the number of additional "soft" cahce entries. Sort of a
two-level cahce. That approach may not meet your needs either, but I just
wanted to point out the possibility.
When we start talking about having a more full-featured cache
("self-balancing"), we're moving beyond the scope of just grabbing a class from
Collections and renaming it. That's not necessarily bad, we just have to weigh
the options.
I'm not sure that using a servlet context init param is magical or non-obvious,
although it still might be ;-). It's the same mechanism that can be used to
perform "static" configuration of certain JSTL features (dynamic configuration
would be the domain of the javax.servlet.jsp.jstl.core.Config class). However,
I agree we need to try and pick a default that's generally useful, but as you
say, that's pretty difficult.
Quoting Daryl Beattie <[EMAIL PROTECTED]>:
> 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/>
--
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]
