tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Tag object pooling and immutability in the servlet spec
Date Sun, 27 Oct 2002 06:57:55 GMT

"Craig R. McClanahan" <> wrote in message
> On 24 Oct 2002, Mr. Tomcat wrote:
> > Date: 24 Oct 2002 17:37:36 -1000
> > From: Mr. Tomcat <>
> > Reply-To: Tomcat Users List <>
> > To:
> > Subject: Tag object pooling and immutability in the servlet spec
> >
> > Is there a way to turn off tag object pooling?  Object pooling was a
> > cool performance technique in earlier versions of Java, but now object
> > creation is very fast, so it no longer serves a performance function,
> > and it introduces extra complexity into tag object design.  Is this
> > misfeature going to be phased out?
> >
> No.  Your assumption that it "no longer serves a performance function" is
> not correct.
> Just as an example of why it still matters, consider something like this
> (using the JSTL iteration tag):
>     <c:forEach var="i" begin="0" end="999">
>       <mytags:foo index="${i}" .../>
>     </c:forEach>
> The tag reuse mechanisms allow a page compiler to create one instance of
> the <mytags:foo. tag and reuse it for every iteration through the loop,
> instead of creating 1000 of them.  No matter how cheap object creation
> gets, there is still a difference -- and that difference is still
> significant on webapps with large numbers of users.

While I haven't tracked it down completely, this is my favorite bug-bear for
the 4.1.x (lack of) performance wrt JSPs.  What Craig isn't telling you is
that 4.1.x will issue 2000 calls to synchronized methods to allocate/release
the tags in the above example.  That's got to hurt :).

Since, at the moment, there is no (practical) way to disable tag-pooling,
I'll have to wait until I disable it in the build to know for sure if this
is why it is so slow.

> If tag reuse really makes your tags more complex, you're probably
> designing them wrong (and I'm talking to myself as well; I've been guilty
> of that particular mistake).
> > Also, on the immutable object topic, it seems that it would be better to
> > have all the initialization of servlets and filters done in the
> > constructor, not by calling an init function.  If everything could be
> > set in the constructor, then all instance fields could be private final,
> > meaning that the servlet or filter object could be immutable, and
> > therefore known to be threadsafe, which is an issue with servlets.  Any
> > chance of these changes happening in future releases of the servlet
> > spec?
> >
> The constructor of a Servlet (or Filter) doesn't have access to the
> ServletConfig (or FilterConfig) object, so it cannot acquire
> initialization parameters, a reference to the ServletContext instance, or
> anything like that.
> Because javax.servlet.Servlet and javax.servlet.Filter are interfaces (not
> classes), you can't declare constructors in them.  Therefore, the servlet
> spec requires that there be a zero-args constructor available so that
> instances can be dynamically instantiated.
> Would it be possible to require servlets and filters to have a constructor
> that takes a ServletConfig (or FilterConfig) argument?  Sure ... at the
> cost of breaking every Servlet or Filter that has ever been written.
> Doesn't seem like a smart idea to implement something that is purely
> cosmetic, and wouldn't change the actual functionality provided by the
> container.  There's much more important things for the spec to address.
> > Thanks
> Craig McClanahan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message