This is a followup to http://markmail.org/thread/777be426ulcfmdd3 and
Mark's remark in the TC 6 status file.
Concerning Entry objects: there were race conditions in the original
code. It is not unlikely that the problem is fixed in 7.0.5.
But there are more interesting memory observations concerning JSPs:
Users switching from TC 5.0 (sic) to newer version note an increased
memory demand when using lots of JSPs. A partial solution is the patch
to unload JSPs when a configured number of loaded JSPs is reached, which
was provided via BZ 48358 and later slightly improved. A backport
proposal for the patch is part of the status file.
When inspecting the patch and especially looking at a multi gigabyte
heap dump, I noticed that lots of memory were consumed by objects which
are generated and primarily only needed during the compilation phase.
This is due to a change in TC 5.5.13 which only applies to development
mode. Since r322516 we keep lots of objects which are generated during
the JSP compilation:
+ // Only get rid of the pageNodes if in production.
+ // In development mode, they are used for detailed
+ // error messages.
+ // http://issues.apache.org/bugzilla/show_bug.cgi?id=37062
+ if(!this.options.getDevelopment()) {
pageNodes = null;
+ }
Remy already remarked at that time about the increased memory use but it
seemed acceptable for development mode (since JSP recompilation can also
be done without development mode using checkInterval).
Caution: I don't exactly remember whether the o.a.jasper.util.Entry
objects mentioned in the original thread were also part of that. I
remember there were *lots* of Stack and Mark objects.
Even without development mode there are some sub optimal constructs. It
seems that more memory could be saved by throwing away the Compiler
object after compilation is done, but this can't be done because at the
moment the function isOutdated() is implemented inside the Compiler.
Finally I noticed another very old inefficiency: whenever modification
timestamps are checked, we actually load the full file contents. That
leads to a lot of garbage production (and IO activity) due to
modification time checks for JSPs.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
