Saxon

Raising the limit on stack size doesn't really help.

(a) The cost of calculating net timings rises quadratically as the stack depth increases, making the timings themselves meaningless

(b) It's not clear anyway what gross and net time mean under heavy recursion

(c) Injecting a trace listener inhibits tail recursion optimization, so we're measuring an artificial execution strategy.

I suggest that when we detect recursion, we suppress net time calculation.

It seems this stack was a rather hastily conceived solution to the problem of how to present aggregated timing data for recursive calls. It seems to be used only to detect that a call is recursive. This could have been done equally well using the existing stack (which uses java.util.Stack and therefore has no limit built in. It's a poor solution to the problem of detecting recursion because it involves a linear search of the stack to find other occurrences of the same instruction.

Replaced it with a Map<Instruction, Integer> which keeps track of the recursion depth for each active instruction.