You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Ken Weiner (JIRA)" <xa...@xml.apache.org> on 2004/11/17 22:40:25 UTC

[jira] Updated: (XALANJ-1973) Memory Leak, Extension functions that return a DTM

     [ http://nagoya.apache.org/jira/browse/XALANJ-1973?page=history ]

Ken Weiner updated XALANJ-1973:
-------------------------------

    Attachment: screenshot-1.jpg

I am seeing a memory leak too that may be related.  Attached is a screen shot of a memory snapshot using YourKit profiler.
The picture shows the references that lead from a StylesheetRoot down to a ElemForEach and eventually to the ChannelManager object which is an object in my application that should have been garbage collected, but hasn't been because of the strong reference remaining from within ElemForEach.
I suspect that the problem is in org.apache.xpath.axes.IteratorPool which seems to hang on to objects in its m_freeStack for too long.  If anyone could elaborate on the intended behavior for IteratorPool, that would help me determine if this class is the problem.

> Memory Leak, Extension functions that return a DTM
> --------------------------------------------------
>
>          Key: XALANJ-1973
>          URL: http://nagoya.apache.org/jira/browse/XALANJ-1973
>      Project: XalanJ2
>         Type: Bug
>   Components: transformation
>     Versions: CurrentCVS
>  Environment: Xalan, current CVS
> JDK 1.4.2_04 (SUN)
>     Reporter: John Gentilin
>  Attachments: FanTest.xsl, screenshot-1.jpg, xsl-apply-templates-backtrace.mht, xsl-apply-templates-heap.mht, xsl-for-each-backtrace.mht
>
> It appears that when an extension function returns a DTM, a reference to the DTM object is held within the transformation engine. 
> This problem is apparent within the SQL Extension but I don't think the extension code is the source of the problem.
> I am including a Stylesheet that can demonstrate the problem along with 2 different back trace files and a heap dump produced from OptimizeIt. The heap dump represents the state of the JVM, after the transformation was completed with a forced GC. The back traces show the allocations of the SQLDocument which extends DTM.
> The stylesheet example is complete and does not require an XML data file. It does require a connection to a JDBC compliant Database. The stylesheet will create the table, insert the test data and run several iterations. 
> At first we were using the xsl:for-each element. Comments in this code lead me to believe that the ElemForEach#transformSelectedNodes may have been responsible. The XSL was then refactored to use xsl:apply-templates but the same memory leak appeared.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org