Mercurial > hg > Members > kono > jpf-core
view src/main/gov/nasa/jpf/jvm/bytecode/INVOKECLINIT.java @ 24:6774e2e08d37
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 |
line wrap: on
line source
/* * Copyright (C) 2014, United States Government, as represented by the * Administrator of the National Aeronautics and Space Administration. * All rights reserved. * * The Java Pathfinder core (jpf-core) platform is licensed under the * Apache License, Version 2.0 (the "License"); you may not use this file except * in compliance with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0. * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package gov.nasa.jpf.jvm.bytecode; import gov.nasa.jpf.vm.ClassInfo; import gov.nasa.jpf.vm.ElementInfo; import gov.nasa.jpf.vm.Instruction; import gov.nasa.jpf.vm.MethodInfo; import gov.nasa.jpf.vm.ThreadInfo; /** * this is an artificial bytecode that we use to deal with the particularities of * <clinit> calls, which are never in the loaded bytecode but always directly called by * the VM. The most obvious difference is that <clinit> execution does not trigger * class initialization. * A more subtle difference is that we save a wait() - if a class * is concurrently initialized, both enter INVOKECLINIT (i.e. compete and sync for/on * the class object lock), but once the second thread gets resumed and detects that the * class is now initialized (by the first thread), it skips the method execution and * returns right away (after deregistering as a lock contender). That's kind of hackish, * but we have no method to do the wait in, unless we significantly complicate the * direct call stubs, which would obfuscate observability (debugging dynamically * generated code isn't very appealing). */ public class INVOKECLINIT extends INVOKESTATIC { public INVOKECLINIT (ClassInfo ci){ super(ci.getSignature(), "<clinit>", "()V"); } @Override public Instruction execute (ThreadInfo ti) { MethodInfo callee = getInvokedMethod(ti); ClassInfo ciClsObj = callee.getClassInfo(); ElementInfo ei = ciClsObj.getClassObject(); if (ciClsObj.isInitialized()) { // somebody might have already done it if this is re-executed if (ei.isRegisteredLockContender(ti)){ ei = ei.getModifiableInstance(); ei.unregisterLockContender(ti); } return getNext(); } // not much use to update sharedness, clinits are automatically synchronized if (reschedulesLockAcquisition(ti, ei)){ // this blocks or registers as lock contender return this; } // if we get here we still have to execute the clinit method setupCallee( ti, callee); // this creates, initializes & pushes the callee StackFrame, then acquires the lock ciClsObj.setInitializing(ti); return ti.getPC(); // we can't just return the first callee insn if a listener throws an exception } @Override public boolean isExtendedInstruction() { return true; } public static final int OPCODE = 256; @Override public int getByteCode () { return OPCODE; } @Override public void accept(JVMInstructionVisitor insVisitor) { insVisitor.visit(this); } }