Saxon

I find it hard to see why the code in 9.6 (apparently) works and that in 9.7 doesn't.

Investigating it, though, I have found a rather better explanation of what's happening here: https://www.farside.org.uk/201510/deadlocks_in_java_class_initialisation

It seems a wonder that it doesn't happen more often, since the examples in that post seem to be very common coding patterns.

I've realised that some of my attempts at diagnostics were defeated by the way the test case is constructed: it fires off a separate JVM Process using exec(), and captures the StandardOutput of that Process. So diagnostic messages easily disappear into thin air.

The separate JVM was needed for isolating the class loading from other tests, and for getting multiple chances of reproducing the problem in a single test execution. For analysing the cause, it might be preferable to use the test that is attached to Bug #2327. When I run it from a Windows command line, and hit CTRL-Break for getting a stack trace while it reports the active threads, this is shown:

"Thread-1" #11 prio=5 os_prio=0 tid=0x00000000162f8000 nid=0x21a8 in Object.wait() [0x0000000016a5d000]
   java.lang.Thread.State: RUNNABLE
        at net.sf.saxon.type.AnyFunctionType.<clinit>(AnyFunctionType.java:30)
        at net.sf.saxon.ma.map.MapNew.<clinit>(MapNew.java:35)
        at net.sf.saxon.Configuration.init(Configuration.java:436)
        at net.sf.saxon.Configuration.<init>(Configuration.java:256)
        at InstantiationProblem$2.run(InstantiationProblem.java:24)

"Thread-0" #10 prio=5 os_prio=0 tid=0x00000000162f5000 nid=0x1e44 in Object.wait() [0x000000001695d000]
   java.lang.Thread.State: RUNNABLE
        at net.sf.saxon.value.SequenceType.<clinit>(SequenceType.java:449)
        at net.sf.saxon.functions.StandardFunction$Entry.arg(StandardFunction.java:1039)
        at net.sf.saxon.functions.StandardFunction.<clinit>(StandardFunction.java:173)
        at com.saxonica.functions.xslt3.StandardFunctionsPE.init(StandardFunctionsPE.java:37)
        at com.saxonica.config.ProfessionalConfiguration.<clinit>(ProfessionalConfiguration.java:122)
        at InstantiationProblem$1.run(InstantiationProblem.java:18)

That points to the static initializers of AnyFunctionType and SequenceType. Haven't looked up their source code yet, but I guess that they could be mutually dependent on each other?

We've both been following in the same path. Here's what I prepared before I saw your post:

Sending output to a log file rather than standard output, here is the stack trace of the two deadlocked processes:

THREAD 1

net.sf.saxon.value.SequenceType.<clinit>(SequenceType.java:450)

net.sf.saxon.functions.StandardFunction$Entry.arg(StandardFunction.java:1042)

net.sf.saxon.functions.StandardFunction.<clinit>(StandardFunction.java:177)

com.saxonica.functions.xslt3.StandardFunctionsPE.init(StandardFunctionsPE.java:37)

com.saxonica.config.ProfessionalConfiguration.<clinit>(ProfessionalConfiguration.java:122)

nativetests.ConfigDeadlockTest$UseFixForSaxonBug2327$1.run(ConfigDeadlockTest.java:76)

THREAD 2

net.sf.saxon.type.AnyFunctionType.<clinit>(AnyFunctionType.java:31)

net.sf.saxon.ma.map.MapNew.<clinit>(MapNew.java:35)

net.sf.saxon.Configuration.init(Configuration.java:442)

net.sf.saxon.Configuration.<init>(Configuration.java:256)

nativetests.ConfigDeadlockTest$UseFixForSaxonBug2327$2.run(ConfigDeadlockTest.java:81)

So the two classes (A,B) are (SequenceType, AnyFunctionType).

Moving the static variable SINGLE_FUNCTION_TYPE from AnyFunctionType to SequenceType appears to solve the problem.

Patch committed on the 9.7 branch.

Great - thanks!

I now get a conflict between SequenceType and MapType - similar, but slightly less obvious how to resolve it.

Michael Kay wrote:

So the two classes (A,B) are (SequenceType, AnyFunctionType).

Hi Mike et al,

My findings are that the two classes that cannot be loaded (initialized) in different threads are

net.sf.saxon.functions.StandardFunction and class net.sf.saxon.expr.Expression because one depends on the other.

I've added this method to a class and I'm sure it is called even before creating a Container

	/**
	 * This method makes sure the class net.sf.saxon.functions.StandardFunction
	 * and the class net.sf.saxon.expr.Expression has been
	 * loaded by the same thread. 
	 * By doing this we are preventing a potential deadlock that happens to occurs 
	 * when the ZipCascadeURIResolver class is loaded asynchronously with the creation
	 * of a DTSContainer.
	 */
	public synchronized static void preventDeadLocks() {
		try {
			// makes sure this class has been loaded and it is initialized prior to create
			// any processor instance
			Class.forName("net.sf.saxon.functions.StandardFunction");
		} catch (ClassNotFoundException e) {
		}
	}