Mercurial > hg > Members > kono > jpf-core

comparison src/main/gov/nasa/jpf/jvm/bytecode/RETURN.java @ 24:6774e2e08d37

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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
author Peter Mehlitz <Peter.C.Mehlitz@nasa.gov>
date Tue, 21 Apr 2015 00:34:15 -0700
parents 61d41facf527
children 8aded593a50f
comparison
equal deleted inserted replaced
23:db918c531e6d 24:6774e2e08d37
31 public class RETURN extends JVMReturnInstruction { 31 public class RETURN extends JVMReturnInstruction {
32 32
33 @Override 33 @Override
34 public Instruction execute (ThreadInfo ti) { 34 public Instruction execute (ThreadInfo ti) {
35 35
36 // Constructors don't return anything so this is the only instruction that can be used to return from a constructor.
37
38 //MethodInfo mi = ti.getMethod(); // Get the current method being executed (e.g. returned from).
39
40 if (mi.isInit()) { // Check to see if this method is a constructor. 36 if (mi.isInit()) { // Check to see if this method is a constructor.
41
42 int objref = ti.getThis(); 37 int objref = ti.getThis();
43 ElementInfo ei = ti.getElementInfo(objref); // Get the object. 38 ElementInfo ei = ti.getElementInfo(objref); // Get the object.
44 39
45 if (!ei.isConstructed()) { // Don't bother doing the following work if the object is already constructed. 40 if (!ei.isConstructed()) { // Don't bother doing the following work if the object is already constructed.
46 41
50 if (ei_ci == mi_ci) { // If the object's class and the method's class are equal, then the thread is returning from the object's constructor. 45 if (ei_ci == mi_ci) { // If the object's class and the method's class are equal, then the thread is returning from the object's constructor.
51 ei = ei.getModifiableInstance(); 46 ei = ei.getModifiableInstance();
52 ei.setConstructed(); 47 ei.setConstructed();
53 } 48 }
54 } 49 }
50
51 } else if (mi.isClinit()) {
52 mi.getClassInfo().setInitialized();
55 } 53 }
56 54
57 return super.execute(ti); 55 return super.execute(ti);
58 } 56 }
59 57