Saxon

My first instinct would be to put this down to unpredictability of garbage collection activity. Certainly I would want to see some indication that GC activity (and memory pressure generally) is being monitored. But I'll get something running myself before coming to a conclusion.

Running with debugging enabled in my experience often causes performance to become unpredictable. I've always assumed that's because it increases the memory requirement, though I have no positive evidence for this.

I use IntelliJ rather than Eclipse, but I should think the effects are very similar.

We could reproduce this independent of the debugger. Further if it is GC and I only pause the processing thread, then I would assume the GC works on the background threads and once I continue the thread it should finish in 4s. Which it does not.

I have not been able to reproduce this; it runs fine for me with or without debugging enabled.

However, I have been running under IntelliJ rather than Eclipse. Our normal support policy is that we don't create custom software environments to investigate problems.

It feels very much like a problem with the environment in which you are running Saxon, rather than a problem with Saxon itself. I would certainly suspect that it is memory related, both (a) because running under a debugger tends to increase the memory requirement, and (b) because you report that allocating more memory solves the problem.

You mention the warning message "Too many nested template or function calls. The stylesheet may be looping." I haven't seen that message either in my own runs, or in your video, so I'm not sure of its relevance.

What I do see in the video, and it seems to be only in the failing runs, is a message suggesting that an error occurred while matching a pattern. Now of course, with a StackOverflowError it's going to be a bit random when you hit the error, because memory allocation is going to be a bit unpredictable. It seems possible that you're hitting a StackOverflow error while doing pattern matching. The XSLT spec requires that errors that occur during pattern matching are ignored (the pattern is treated as not matching), so it's possible that what's happing here is that Saxon tries to recover from the error, but because an error during pattern matching is treated as a non-match, this could take your stylesheet code into a path where it fires different template rules, which could cause execution to follow a completely different path from then on.

The intent of the rule about ignoring errors in pattern matching is to handle cases where you write a pattern like `match="*[@id eq 3]" and it fails because the id attribute of that particular element isn't an integer. Treating that as a non-match makes sense. Ignoring a problem that arose through not having enough memory doesn't make much sense, so we should probably handle that one differently.