Mantis - Resin
Viewing Issue Advanced Details
5914 major always 06-02-15 15:33 06-09-15 14:20
nfedorov  
ferg  
normal  
closed 4.0.43  
fixed  
none    
none 4.0.45  
0005914: JSP tag classes leaking
Resin creates a new class loader anytime a JSP class needs to be loaded. If a JSP page happens to use JSP tags (defined in *.tag files), the class of each tag is loaded using the same class loader, along with the main JSP class.

If there are 100 JSP pages using the same JSP tag, the class of the tag will be loaded 100 times, once with each JSP page, creating 100 tag class duplicates.

The problem affects only JSP tags (*.tag files), not Java tags defined in *.tld files.

Not only this seems to be a performance problem since the same JSP tag classes are loaded and defined over and over, it also creates a memory leak since many class duplicates coexist in PermGen eating up the space.

Further, anytime a JSP class is cached in memory, its class loader cannot be unloaded and all of the JSP tag classes loaded by that class loader stay in memory too.

For example, the ReflectionAnnotationFactory holds a WeakHashMap of introspected types. Every JSP class is introspected and cached in that map. The values are softly referenced and so the JSP classes are kept in memory for a while, along with their respective class loaders and all of the JSP tag class duplicates loaded with that JSP.

===

The application we run on resin heavily relies on JSP tags and we can see thousands of JSP tag class duplicates in memory dumps (70-80% of total amount of loaded classes in some cases).

At some point, GC seems to start unloading softly referenced JSP classes along with the JSP tag classes at a higher rate to avoid OutOfMemoryError in PermGen region, but then these JSPs are loaded back upon the next use.

Loading/unloading of JSP classes at high rate degrades the performance of the application. Thread dumps show ClassLoader.defineClass on top of stacktraces of many threads when this happens.

Increasing the size of PermGen region alleviates the problem, but does not solve it as the class duplicates are still kept in memory.

===

To reproduce, define a simple JSP tag, use it in two JSP pages, deploy the webapp and visit both JSP pages, inspect the content of memory for class duplicates, notice the dangling class loaders and classes they loaded.

There are no notes attached to this issue.