Bug 43878 - Tag-file classes get loaded for each JSP -> perm gen space problem
Summary: Tag-file classes get loaded for each JSP -> perm gen space problem
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 6.0.10
Hardware: All All
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
: 55150 (view as bug list)
Depends on:
Reported: 2007-11-16 01:20 UTC by Christoph Korn
Modified: 2014-02-17 13:43 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Korn 2007-11-16 01:20:37 UTC
If you use the same tag (defined in a JSP 2.0 tag file) on two different JSPs,
the tag-class will get loaded from two different classloaders resulting in two
loaded classes in the perm gen space. You can trace this behaviour when starting
the VM with the arguments "-XX:+TraceClassLoading -XX:+TraceClassUnloading". The
classes get loaded multiple times even when development/reloading is disabled.

This behaviour gets a problem if you have a huge number of JSPs (in our case
>10.000) and a few tags used on every single JSP.

I traced down the problem in the source code:

For each JSP to compile, a new instance of a JspCompilationContext is used. The
JspCompilationContext holds a reference to a JasperLoader (a ClassLoader), which
initially is null (a new JasperLoader will be created when it is first used).
The JspCompilationContext will not only load the JSP class, but also compiles
and loads tag-files referenced within the JSP. As the JasperLoader loads all
classes starting with "org.apache.jsp" by itself and does not delegate to it's
parent, the tag class (which lies underneath this package) will get loaded via
multiple JasperLoader instances.

I perfectly understand that loading each JSP via a different classloader may be
necessary, when reloading is enabled, but if reloading/development is disabled,
the same JasperLoader instance could be used. This would prevent the tag class
to get loaded multiple times. (I.e. a previously used JasperLoader instance
could be passed to the JspCompilationContext, if running in production mode).

By the way I think that loading the tag file via the same classloader as the JSP
in a reloading-enviornmane may result in some strange behaviour: If two JSPs use
the same tag and you change the tag as well as one JSP, you'll see the new
version of the tag on the reloaded JSP, but the previous version of the same tag
(but loaded via a different class-instance) on the unchanged JSP. But to solve
this issue, some greater refactoring would be necessary, I think....
Comment 1 Mark Thomas 2007-12-29 11:31:52 UTC
I have committed the following fix for this to trunk.

Feedback from any testing you could do would be much appreciated.
Comment 2 Philipp Traeder 2007-12-30 04:32:10 UTC
Hi Mark,

thank you very much!

We'll test the new version first thing in the new year and let you know the results.

Have a good start into 2008,
Comment 3 Mark Thomas 2008-01-26 11:30:47 UTC
Looking at it, my patch is clearly nonsense. I'm working on one that actually
Comment 4 Philipp Traeder 2008-01-26 14:53:16 UTC
Hi Mark,

thanks for the heads-up - I´ll forward it to my colleagues to let them know that
they don't need to start testing.

Comment 5 Mark Thomas 2008-01-29 15:39:26 UTC
I have committed a better fix for this to trunk. Any testing results you can
provide would be much appreciated.

The fix has also been proposed for 6.0.x.
Comment 6 Mark Thomas 2008-02-21 14:00:09 UTC
This patch has been sat in the proposals list for a few weeks and hasn't
gathered much interest.

Remy commented that the use case is very close to the pre-compilation one which
likely explains why there isn't much support for the patch.

On this basis I marking this bug as WONTFIX on the grounds pre-compilation
achieves pretty much the same result.

You are of course, free to use the patch in your own environment if it is useful
to you. I have included a link to my improved patch for this below:
Comment 7 Mark Thomas 2013-06-27 20:05:15 UTC
*** Bug 55150 has been marked as a duplicate of this bug. ***