Saxon

Example of call hierarchy that is hitting the synchronized block.

net.sf.saxon.functions.SystemFunctionLibrary.getSystemFunctionLibrary(int, Configuration)

net.sf.saxon.sxpath.AbstractStaticContext.setDefaultFunctionLibrary()

net.sf.saxon.xpath.JAXPXPathStaticContext.(Configuration)

net.sf.saxon.xpath.XPathEvaluator.(Configuration)

net.sf.saxon.xpath.XPathFactoryImpl.newXPath()

The SystemFunctionLibrary has been completely redesigned for 9.8 and I think this particular contention spot should disappear. But we should probably look top-down at the performance of a workload that's doing a large number of XPath compile-and-go operations.

I suspect you might get better throughput if you run at lower concurrency?

And I wonder if you would get better performance if you used the s9api interface rather than JAXP? Unlike the JAXP XPath object, the s9api XPathCompiler is thread-safe once configured, and I suspect it has a significantly lower initialisation cost.

(Actually, Saxon's implementation of the JAXP XPath interface is thread-safe once configured, even though the API says it doesn't have to be.)

Thanks! I'll have to try the next release of 9.8 and I'll experiment with the s9api.