Saxon

Thanks for reporting it. I've reproduced the results and have no immediate idea of the cause.

A rather strange effect is the execution profile counts for 9.7.0.6, many of which are powers of 2:

file line instruction count average time (gross) total time (gross) average time (net) total time (net)

"*ascript.xquery" 7212 function p:parse-NumericLiteral 65536 0.019 1229.020 0.017 1135.094

"*ascript.xquery" 7538 function p:parse-MemberExpression 32768 0.146 4793.314 0.028 914.005

"*ascript.xquery" 7271 function p:parse-Literal 65536 0.031 2053.640 0.012 772.322

"*ascript.xquery" 7342 function p:parse-PrimaryExpression 65536 0.043 2838.317 0.011 734.901

"*ascript.xquery" 7764 function p:parse-LeftHandSideExpression 32768 0.187 6118.195 0.017 557.469

"*ascript.xquery" 4518 function p:parse-UnaryExpression 32768 0.218 7151.053 0.015 490.553

"*ascript.xquery" 4425 function p:parse-PostfixExpression 32768 0.202 6633.534 0.015 483.854

whereas the corresponding execution counts for 9.7.0.5 are typically 1 or 2.

More specifically, in 9.7.0.5 there is one call on p:parse-Program resulting in 2 calls on p:parse-Program-1; in 9.7.0.6 there is one call on p:parse-Program resulting in 4 calls on p:parse-Program-1; and the doubling of calls seems to continue in the same vein.

Confirmed that the problem also occurs in the current 9.8 code, and that it still occurs with bytecode generation off.

But it goes away if optimisation is disabled (-opt:0).

(Note, there's an oddity in the profile output: multiple entries for the p:trace function on line 664. I guess this is because there are multiple copies of the function body as a result of inlining, and we're failing to combine them for profiling purposes.)

The problem does not go away if tail call optimization is disabled (which can only be done by commenting out code internally).

This is proving very difficult to track down.

The most obvious symptom of the problem is that function parse-Program-1 makes three recursive calls on itself when it should only make one. The reason it does so is that the $state variable indicates that parsing has not yet finished. I think we need to pin down at what point the value of $state deviates from previous releases. This is hampered by the fact that (as a result of the changes made under bug #2707) there are legitimate differences in the detailed execution plan.

Thanks for resolving this so quickly! I have fetched the fix from svn an I can confirm that it works fine now.