RE: [xsl] recursion troubles --Xalan, Saxon, msxml, xt --

Subject: RE: [xsl] recursion troubles --Xalan, Saxon, msxml, xt --
From: "Michael Kay" <mhkay@xxxxxxxxxxxx>
Date: Thu, 15 Feb 2001 15:08:24 -0000
> From: Eric Vermetten
> Instant Saxon 6.0.2.
> 1-251     correct output
> 252       *no* output: the NT command line just silently reappears
> 253       java.lang.StackOverflowError
> 254       *no* output: the NT command line just silently reappears
> 255,256   java.lang.StackOverflowError
>       --this is were I stopped
> Bug for 252 and 254?

I can't reproduce or explain the odd results for 252 and 254. Probably a
secondary error in the exception handling in a .exe created using the
Microsoft jexegen tool.

I ran the example with my default setup and got the stack overflow at a
depth of around 960 with JDK 1.3, and around 6500 with Microsoft java.
Obviously the limit is going to depend on the settings of the various Java
switches that control stack space allocation.

If you rewrite the template so that it is tail-recursive, like this:

<xsl:template name="reverse2">
   <xsl:param name="index" />
   <xsl:param name="curr" select="1"/>
    <xsl:value-of select="concat($curr,'|')" />;
    <xsl:if test="$curr &lt;= $index">
        <xsl:call-template name="reverse2">
           <xsl:with-param name="index" select="$index" />
           <xsl:with-param name="curr" select="$curr+1" />

then it gets up to a million iterations without difficulty, or further, if
you've got the patience to wait for it. (I tried 1,000,000 and it took 55
seconds). It's definitely worth coding to invoke tail recursion if you can:
the rule is essentially that tail recursion is used when nothing significant
happens after the call on xsl:call-template and before the template exits.

Mike Kay
> Xalan 1.2.2.
> 1-859     correct output
> 860       EXCEPTION_STACK_OVERFLOW exception
> 861       HotSpot Virtual Machine Error, EXCEPTION_STACK_OVERFLOW
>           suggests making a bug report (which I did)
> 862       EXCEPTION_STACK_OVERFLOW exception,
>       --this is where I stopped
> Bug for 861
> msxml prod release  -no evil empires here-
> 1 - 4000  correct output
> xt, xt.dll from XMetal 1.0
> 1 - 4000  corect output
> Why are those Java based processors having such a hard time
> with keeping their runtime stack in order? Why is there such
> a big difference between instant Saxon and Xalan? Both are
> java based. Shouldn't the runtime stack space only be limited
> by available memory? Can someone give me some explanation?
> Thanks in advance,
> Eric Vermetten
>  XSL-List info and archive:

 XSL-List info and archive:

Current Thread