Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 30848 invoked from network); 16 Nov 2007 09:21:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Nov 2007 09:21:09 -0000 Received: (qmail 44699 invoked by uid 500); 16 Nov 2007 09:20:47 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 44668 invoked by uid 500); 16 Nov 2007 09:20:47 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 44654 invoked by uid 500); 16 Nov 2007 09:20:47 -0000 Delivered-To: apmail-jakarta-tomcat-dev@jakarta.apache.org Received: (qmail 44650 invoked by uid 99); 16 Nov 2007 09:20:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Nov 2007 01:20:46 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Nov 2007 09:20:45 +0000 Received: by brutus.apache.org (Postfix, from userid 33) id CDCFB71420D; Fri, 16 Nov 2007 01:20:38 -0800 (PST) From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Subject: DO NOT REPLY [Bug 43878] New: - Tag-file classes get loaded for each JSP -> perm gen space problem Message-ID: X-Bugzilla-Reason: AssignedTo Date: Fri, 16 Nov 2007 01:20:38 -0800 (PST) X-Virus-Checked: Checked by ClamAV on apache.org DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43878 Summary: Tag-file classes get loaded for each JSP -> perm gen space problem Product: Tomcat 6 Version: 6.0.10 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: c.korn@codekultur.de 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.... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org