Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@apache.org Received: (qmail 76662 invoked from network); 10 Mar 2003 21:52:18 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 10 Mar 2003 21:52:18 -0000 Received: (qmail 17674 invoked by uid 97); 10 Mar 2003 21:54:04 -0000 Delivered-To: qmlist-jakarta-archive-struts-dev@nagoya.betaversion.org Received: (qmail 17667 invoked from network); 10 Mar 2003 21:54:04 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 10 Mar 2003 21:54:04 -0000 Received: (qmail 75986 invoked by uid 500); 10 Mar 2003 21:52:10 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 75925 invoked from network); 10 Mar 2003 21:52:10 -0000 Received: from cyber.s1.com (HELO s1.com) (139.131.240.43) by daedalus.apache.org with SMTP; 10 Mar 2003 21:52:10 -0000 Received: from ([139.131.240.36]) by cyber.s1.com with SMTP ; Mon, 10 Mar 2003 16:49:47 -0500 (EST) Received: from 139.131.240.30 by Panacea.s1.com (InterScan E-Mail VirusWall NT); Mon, 10 Mar 2003 16:50:19 -0500 Received: by nrcw2kexg01.norc.s1.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 16:47:09 -0500 Message-ID: From: Christophe Warland To: "'struts-dev@jakarta.apache.org'" Cc: "'cedric@apache.org'" , "'cedric.dumoulin@lifl.fr'" Subject: Tiles excessive memory usage Date: Mon, 10 Mar 2003 16:47:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b0710df5-89b8-406f-ae98-d6a60bd455cd" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------=_NextPartTM-000-b0710df5-89b8-406f-ae98-d6a60bd455cd Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E74E.9A085D60" ------_=_NextPart_001_01C2E74E.9A085D60 Content-Type: text/plain; charset="iso-8859-1" At my company, we have been recently forced to patch Tiles to solve some major memory problems where Tiles was eating a lot of memory for no apparent reasons. We wish to share our findings with you. And we will be happy to send our code change to Cedric if he wishes so. Here are some quick numbers about our J2EE runtime after complete bootup (appserver and EAR file are up, deployed and ready to serve HTTP requests): - With original Tiles code: 79 MB of RAM is used - After our custom code change: 28 MB of RAM is used Note that the Tiles version that we use is an old one (our source zip shows 09/10/2001). However, a quick analysis of the more recent Tiles source found in Struts 1.1 RC1 shows that most the code where the defect lies is still in there. But we haven't actually been able to confirm the problem at runtime since our app is not compatible with the latest Struts and Tiles development. Here are a few excerpt of our internal analysis so that you can understand the issue. -- Our application does not actually make use of the Tiles template mechanism but instead builds on top of Tiles' i18n concept to offer localized Web pages based on an individual's language, country, personality and channel. We make extensive use of Tiles Component definitions and inheritance in XML files, and 667 out of the 668 definitions used by our app inherit from another one. With the help of a Java profiler, we showed that 64% of the 79 MB of memory was used by HashMap entries created by Tiles. This corresponds to 50.5 MB of RAM. After close investigation, it turns out that the very useful Tiles' component inheritance has been mis-implemented. Our application has only one definition that doesn't extend another one: the root "pageDefinition", which contains common information such as "pageCopyrightLink" for example. Other Component Definitions that extend "pageDefinition", such as "disbursementCB", do not need to repeat this information. When queried for the "pageCopyrightLink" value, the "disbursementCB" component will delegate the processing to its parent component, in this case "pageDefinition". Unfortunately, this handy conceptual delegation is actually not implemented in a similar way in the Tiles source code. In our example, when the "disbursementCB" component is instantiated in memory, the Tiles source code does not pass it a reference to the parent "pageDefiniton" component. Instead, Tiles forces the new "disbursementCB" component to make a deep copy of all values defined in its parent(s). This means that, ultimately, our application ends up with 668 copies of the "pageCopyrightLink" value in memory, instead of one. After modification of the Tiles source code so that true delegation is actually happening in memory at runtime, new heap allocation statistics showed that the problem with excessive usage of HashMap$Entry has been completely solved. The most in-use object in the JVM is now of the type "[C", a common and normal trend in typical Java applications. The total amount of memory was also down to 28 MB. This is a pleasant 51 MB gain over the previous result. -- Finally, without being too demanding, we would appreciate if a patched version of Tiles could be made available for for both the upcoming Struts 1.1 release and the current stabe Strust 1.0.2 one. Best Regards, Christophe Warland ------_=_NextPart_001_01C2E74E.9A085D60 Content-Type: text/html; charset="iso-8859-1"

At my company, we have been recently forced to patch Tiles to solve some major memory problems where Tiles was eating a lot of memory for no apparent reasons. We wish to share our findings with you. And we will be happy to send our code change to Cedric if he wishes so.

Here are some quick numbers about our J2EE runtime after complete bootup (appserver and EAR file are up, deployed and ready to serve HTTP requests):
- With original Tiles code: 79 MB of RAM is used
- After our custom code change: 28 MB of RAM is used

Note that the Tiles version that we use is an old one (our source zip shows 09/10/2001). However, a quick analysis of the more recent Tiles source found in Struts 1.1 RC1 shows that most the code where the defect lies is still in there. But we haven't actually been able to confirm the problem at runtime since our app is not compatible with the latest Struts and Tiles development.

Here are a few excerpt of our internal analysis so that you can understand the issue.

Our application does not actually make use of the Tiles template mechanism but instead builds on top of Tiles' i18n concept to offer localized Web pages based on an individual's language, country, personality and channel. We make extensive use of Tiles Component definitions and inheritance in XML files, and 667 out of the 668 definitions used by our app inherit from another one.

With the help of a Java profiler, we showed that 64% of the 79 MB of memory was used by HashMap entries created by Tiles. This corresponds to 50.5 MB of RAM. After close investigation, it turns out that the very useful Tiles' component inheritance has been mis-implemented.

Our application has only one definition that doesn't extend another one: the root "pageDefinition", which contains common information such as "pageCopyrightLink" for example. Other Component Definitions that extend "pageDefinition", such as "disbursementCB", do not need to repeat this information. When queried for the "pageCopyrightLink" value, the "disbursementCB" component will delegate the processing to its parent component, in this case "pageDefinition".

Unfortunately, this handy conceptual delegation is actually not implemented in a similar way in the Tiles source code.

In our example, when the "disbursementCB" component is instantiated in memory, the Tiles source code does not pass it a reference to the parent "pageDefiniton" component. Instead, Tiles forces the new "disbursementCB" component to make a deep copy of all values defined in its parent(s). This means that, ultimately, our application ends up with 668 copies of the "pageCopyrightLink" value in memory, instead of one.

After modification of the Tiles source code so that true delegation is actually happening in memory at runtime, new heap allocation statistics showed that the problem with excessive usage of HashMap$Entry has been completely solved. The most in-use object in the JVM is now of the type "[C", a common and normal trend in typical Java applications.

The total amount of memory was also down to 28 MB. This is a pleasant 51 MB gain over the previous result.

Finally, without being too demanding, we would appreciate if a patched version of Tiles could be made available for for both the upcoming Struts 1.1 release and the current stabe Strust 1.0.2 one.

Best Regards,

Christophe Warland

------_=_NextPart_001_01C2E74E.9A085D60-- ------=_NextPartTM-000-b0710df5-89b8-406f-ae98-d6a60bd455cd Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: struts-dev-help@jakarta.apache.org ------=_NextPartTM-000-b0710df5-89b8-406f-ae98-d6a60bd455cd--