the fix I would have liked to avoid - apparently hotspot internally does nested locking during class init, which can lead to deadlocks such as described in http://ternarysearch.blogspot.ru/2013/07/static-initialization-deadlock.html. Actually, it's not a regular deadlock since core dumps still list the threads as runnable, althouth it doesn't seem to be a livelock either. In any case, it can be simulated by nested locking and clinit execution, and it is such a serious defect that we want to be able to catch it. The general mechanism is to replace the disparate (but properly ordered) direct clinit calls of the generic ClassInfo.initializeClass() with a single sythetic method that includes all required locking (bottom up), clinit calls / class status change (top down), and unlocking (top down). We also need to add a synthetic insn to defer changing the class status of classes that don't have clinits(), or otherwise the correct lock/unlock order will not amount to anything if the hierarchy is entered through one of the clinit-absent classes. Now we get proper deadlocks if there are concurrent cyclic dependencies during class resolution. However, this can be such a state exploder that we certainly don't want this as the default behavior, especially since it probably is hotspot specific. Nested class init locking is therefore controlled by jvm.nested_init and respective jvm.nested_init.include/exclude options. Added a NestedInitTest to demonstrate use. Thanks to Lilia Abdulina for bringing this long forgotten issue up In the wake of nested locks, there were a number of cases to fix that implicitly relied on absent clinits because clients were not properly checking for re-execution (most notably java.util.Exchanger). This mostly came in through MJIEnv.newObject/ElementInfo. We might turn ClinitRequired into a handled exception at some point, to catch such cases during compilation. Added a UnknownJPFClass exception (in analogy to ClinitRequired), to make clients aware of failed class load attempts/reasons. fixed Exchanger peer, which was not giving up the lock when timing out. This is an example of a lockfree wait op that can time out. Basically, ThreadInfo.isWaiting() needs to be complemented by a isWaitingOrTimedOut(), and ElementInfo.notifies0() has to be aware of it fixed NPE when setting report.probe_interval in tests, which was missing that it had to create a stat object

--- a/src/tests/gov/nasa/jpf/test/mc/threads/ClinitTest.java	Wed Apr 15 22:40:21 2015 -0700
+++ b/src/tests/gov/nasa/jpf/test/mc/threads/ClinitTest.java	Tue Apr 21 00:34:15 2015 -0700
@@ -29,58 +29,59 @@
 
   static class X {
     static int x;
+
     static {
       Verify.threadPrintln("initializing X");
-      assertTrue( x == 0);
+      assertTrue(x == 0);
       x++;
     }
   }
-  
+
   @Test
-  public void testNoConcurrentClinit () {
+  public void testNoConcurrentClinit() {
     if (verifyNoPropertyViolation()) {
-   
+
       Runnable r = new Runnable() {
         @Override
-		public void run() {
+        public void run() {
           int x = X.x;
         }
       };
       Thread t = new Thread(r);
       t.start();
-      
+
       int x = X.x;
-      assertTrue( "x = " + x, x == 1);
+      assertTrue("x = " + x, x == 1);
     }
   }
-  
-  
+
+
   static class Y {
     static long y;
-    
+
     static {
       Thread t = Thread.currentThread();
-       Verify.threadPrintln("initializing Y");
+      Verify.threadPrintln("initializing Y");
       y = t.getId();
     }
   }
-  
+
   @Test
   public void testClinitChoices() {
     if (verifyAssertionErrorDetails("gotcha")) {
       Runnable r = new Runnable() {
         @Override
-		public void run() {
+        public void run() {
           long y = Y.y;
         }
       };
       Thread t = new Thread(r);
       t.start();
-      
+
       long y = Y.y;
       Thread tCur = Thread.currentThread();
       Verify.threadPrintln("testing Y.y");
-      assertTrue( "gotcha", y == tCur.getId());
+      assertTrue("gotcha", y == tCur.getId());
     }
   }
 }