Author: markt
Date: Mon May 16 14:48:31 2016
New Revision: 1744058
URL: http://svn.apache.org/viewvc?rev=1744058&view=rev
Log:
No functional change. Update comments with latest understanding of the problem.
Modified:
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
Modified:
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?rev=1744058&r1=1744057&r2=1744058&view=diff
==============================================================================
---
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
Mon May 16 14:48:31 2016
@@ -115,11 +115,11 @@ public class JreMemoryLeakPreventionList
}
/**
- * XML parsing can pin a web application class loader in memory. This is
- * particularly nasty as profilers (at least YourKit and Eclipse MAT) don't
- * identify any GC roots related to this.
- * <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6916498";>
- * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6916498</a>
+ * XML parsing can pin a web application class loader in memory. There are
+ * multiple root causes for this. Some of these are particularly nasty as
+ * profilers may not identify any GC roots related to the leak. For
example,
+ * with YourKit you need to ensure that HPROF format memory snapshots are
+ * used to be abel to trace some of the leaks.
*/
private boolean xmlParsingProtection = true;
public boolean isXmlParsingProtection() { return xmlParsingProtection; }
@@ -290,23 +290,29 @@ public class JreMemoryLeakPreventionList
* Various leaks related to the use of XML parsing.
*/
if (xmlParsingProtection) {
- /*
- * Haven't got to the root of what is going on with this
- * leak but if a web app is the first to make the following
- * two calls the web application class loader will be
pinned
- * in memory.
- */
+ // There are three known issues with XML parsing
+ // 1.
DocumentBuilderFactory.newInstance().newDocumentBuilder();
+ //
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6916498
+ // This issue is fixed in Java 7 onwards
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
try {
DocumentBuilder documentBuilder =
factory.newDocumentBuilder();
- // Bug 58486 identified two additional memory leaks.
- // The first is in DOMSerializerImpl.abort
+
+ // The 2nd and 3rd links both relate to cached
Exception
+ // instances that retain a link to the TCCL via the
+ // backtrace field. Note that YourKit only shows this
+ // field when using the HPROF format memory snapshots.
+ // https://bz.apache.org/bugzilla/show_bug.cgi?id=58486
+ // These issues are currently present in all current
+ // versions of Java
+
+ // 2.
com.sun.org.apache.xml.internal.serialize.DOMSerializerImpl
Document document = documentBuilder.newDocument();
document.createElement("dummy");
DOMImplementationLS implementation =
(DOMImplementationLS)document.getImplementation();
implementation.createLSSerializer().writeToString(document);
- // The second leak is in DOMNormalizer
+ // 3.
com.sun.org.apache.xerces.internal.dom.DOMNormalizer
document.normalize();
} catch (ParserConfigurationException e) {
log.error(sm.getString("jreLeakListener.xmlParseFail"),
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
