Saxon

Reproduced the problem on 9.6 (but not on 9.7). JUnit test case added: ThreadedKeyTest/testConcurrentInstantiation().

Which version of the JDK are you using? Oracle claim to have improved classloading in JDK 1.7 to reduce the possibilities for deadlock:

http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html

Apart from that, it's not clear that there's much we can do about the problem - it seems outside our control.

In my environment it is consistently reproducible with JDK 1.6, JDK 1.7, and JDK 1.8. The latest compiler and runtime that I tested was 1.8.0_31.

I tested on Windows 7 Enterprise, but the test suite usually runs on Redhat Linux and it originally happened there. We also added a specific test for the issue and found that on the build server it only reproduces in 70% of test runs. But this may be due to limitations of the build server with respect to multithreading, or depend on its load.

Thanks. Do you have any suggestions as to anything we might do about it?

The literature on deadlocks in class-loading is fairly mind-blowing. And my experience of this area is that if you make significant changes, you break something - it's an area where it's impossible for us to test the variety of class-loading strategies used in different environments such as Eclipse, Spring, JBoss, etc.

I think I'd move the Class.forName outside of the static initialization by lazily initializing configurationClass. Have just tried this on 9.6.0.3 and it appears to solve the issue:

113c113
<     public static final Class<? extends Configuration> configurationClass = makeConfigurationClass();
---
>     private static final Class<? extends Configuration> configurationClass = null;
346a347,353
>     public static Class<? extends Configuration> getConfigurationClass() {
>       if (configurationClass == null) {
>          makeConfigurationClass();
>       }
>       return configurationClass;
>     }
>
348c355
<         //System.err.println("New configuration: " + configurationClass.getName());
---
>         //System.err.println("New configuration: " + getConfigurationClass().getName());
350c357
<             return configurationClass.newInstance();
---
>             return getConfigurationClass().newInstance();

Though I have only modified the Configuration class, did not check whether there are reasons for configurationClass to be public.

That might indeed work, though it has the mutual reference at class loading time. I just ran my test with the initialization changed to

    public static final Class<? extends Configuration> configurationClass = com.saxonica.config.EnterpriseConfiguration.class;

and it did not produce a deadlock.

Thanks!