Memory consumption when using JSPs

[Rainer Jung <ra...@kippdata.de>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org