dependencies.hpp revision 0
0N/A * Copyright 2005-2006 Sun Microsystems, Inc. All Rights Reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 0N/A * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, 0N/A * CA 95054 USA or visit www.sun.com if you need additional information or 0N/A * have any questions. 0N/A//** Dependencies represent assertions (approximate invariants) within 0N/A// the class hierarchy. An example is an assertion that a given 0N/A// method is not overridden; another example is that a type has only 0N/A// one concrete subtype. Compiled code which relies on such 0N/A// assertions must be discarded if they are overturned by changes in 0N/A// the class hierarchy. We can think of these assertions as 0N/A// approximate invariants, because we expect them to be overturned 0N/A// very infrequently. We are willing to perform expensive recovery 0N/A// operations when they are overturned. The benefit, of course, is 0N/A// performing optimistic optimizations (!) on the object code. 0N/A// Changes in the class hierarchy due to dynamic linking or 0N/A// class evolution can violate dependencies. There is enough 0N/A// indexing between classes and nmethods to make dependency 0N/A// checking reasonably efficient. 0N/A // Note: In the comments on dependency types, most uses of the terms 0N/A // subtype and supertype are used in a "non-strict" or "inclusive" 0N/A // sense, and are starred to remind the reader of this fact. 0N/A // Strict uses of the terms use the word "proper". 0N/A // Specifically, every class is its own subtype* and supertype*. 0N/A // (This trick is easier than continually saying things like "Y is a 0N/A // subtype of X or X itself".) 0N/A // Sometimes we write X > Y to mean X is a proper supertype of Y. 0N/A // The notation X > {Y, Z} means X has proper subtypes Y, Z. 0N/A // The notation X.m > Y means that Y inherits m from X, while 0N/A // X.m > Y.m means Y overrides X.m. A star denotes abstractness, 0N/A // as *I > A, meaning (abstract) interface I is a super type of A, 0N/A // or A.*m > B.m, meaning B.m implements abstract method A.m. 0N/A // In this module, the terms "subtype" and "supertype" refer to 0N/A // Java-level reference type conversions, as detected by 0N/A // "instanceof" and performed by "checkcast" operations. The method 0N/A // Klass::is_subtype_of tests these relations. Note that "subtype" 0N/A // is richer than "subclass" (as tested by Klass::is_subclass_of), 0N/A // since it takes account of relations involving interface and array 0N/A // To avoid needless complexity, dependencies involving array types 0N/A // are not accepted. If you need to make an assertion about an 0N/A // array type, make the assertion about its corresponding element 0N/A // types. Any assertion that might change about an array type can 0N/A // be converted to an assertion about its element type. 0N/A // Most dependencies are evaluated over a "context type" CX, which 0N/A // stands for the set Subtypes(CX) of every Java type that is a subtype* 0N/A // of CX. When the system loads a new class or interface N, it is 0N/A // responsible for re-evaluating changed dependencies whose context 0N/A // type now includes N, that is, all super types of N. 0N/A // An 'evol' dependency simply notes that the contents of the 0N/A // method were used. If it evolves (is replaced), the nmethod 0N/A // must be recompiled. No other dependencies are implied. 0N/A // A context type CX is a leaf it if has no proper subtype. 0N/A // An abstract class CX has exactly one concrete subtype CC. 0N/A // The type CX is purely abstract, with no concrete subtype* at all. 0N/A // The concrete CX is free of concrete proper subtypes. 0N/A // Given a method M1 and a context class CX, the set MM(CX, M1) of 0N/A // "concrete matching methods" in CX of M1 is the set of every 0N/A // concrete M2 for which it is possible to create an invokevirtual 0N/A // or invokeinterface call site that can reach either M1 or M2. 0N/A // That is, M1 and M2 share a name, signature, and vtable index. 0N/A // We wish to notice when the set MM(CX, M1) is just {M1}, or 0N/A // perhaps a set of two {M1,M2}, and issue dependencies on this. 0N/A // The set MM(CX, M1) can be computed by starting with any matching 0N/A // concrete M2 that is inherited into CX, and then walking the 0N/A // subtypes* of CX looking for concrete definitions. 0N/A // The parameters to this dependency are the method M1 and the 0N/A // context class CX. M1 must be either inherited in CX or defined 0N/A // in a subtype* of CX. It asserts that MM(CX, M1) is no greater 0N/A // An "exclusive" assertion concerns two methods or subtypes, and 0N/A // declares that there are at most two (or perhaps later N>2) 0N/A // specific items that jointly satisfy the restriction. 0N/A // We list all items explicitly rather than just giving their 0N/A // count, for robustness in the face of complex schema changes. 0N/A // A context class CX (which may be either abstract or concrete) 0N/A // has two exclusive concrete subtypes* C1, C2 if every concrete 0N/A // subtype* of CX is either C1 or C2. Note that if neither C1 or C2 0N/A // are equal to CX, then CX itself must be abstract. But it is 0N/A // also possible (for example) that C1 is CX (a concrete class) 0N/A // and C2 is a proper subtype of C1. 0N/A // This dependency asserts that MM(CX, M1) is no greater than {M1,M2}. 0N/A // This dependency asserts that no instances of class or it's 0N/A // subclasses require finalization registration. 0N/A // handy categorizations of dependency types: 0N/A // A "context type" is a class or interface that 0N/A // provides context for evaluating a dependency. 0N/A // When present, it is one of the arguments (dep_context_arg). 0N/A // If a dependency does not have a context type, there is a 0N/A // default context, depending on the type of the dependency. 0N/A // This bit signals that a default context has been compressed away. 0N/A // State for writing a new set of dependencies: 0N/A // return true if we've already seen dept/x 0N/A // Initialize _deps, etc. 0N/A // State for making a new set of dependencies: 0N/A // Make a new empty dependencies set. 0N/A // Check for a valid context type. 0N/A // Enforce the restriction against array types. 0N/A // Adding assertions to a new dependency set at compile time: 0N/A // Define whether a given method or type is concrete. 0N/A // These methods define the term "concrete" as used in this module. 0N/A // For this module, an "abstract" class is one which is non-concrete. 0N/A // Future optimizations may allow some classes to remain 0N/A // non-concrete until their first instantiation, and allow some 0N/A // methods to remain non-concrete until their first invocation. 0N/A // In that case, there would be a middle ground between concrete 0N/A // and abstract (as defined by the Java language and VM). 0N/A // These versions of the concreteness queries work through the CI. 0N/A // The CI versions are allowed to skew sometimes from the VM 0N/A // (oop-based) versions. The cost of such a difference is a 0N/A // (safely) aborted compilation, or a deoptimization, or a missed 0N/A // optimization opportunity. 0N/A // In order to prevent spurious assertions, query results must 0N/A // remain stable within any single ciEnv instance. (I.e., they must 0N/A // not go back into the VM to get their value; they must cache the 0N/A // bit in the CI, either eagerly or lazily.) 0N/A // As a general rule, it is OK to compile under the assumption that 0N/A // a given type or method is concrete, even if it at some future 0N/A // point becomes abstract. So dependency checking is one-sided, in 0N/A // that it permits supposedly concrete classes or methods to turn up 0N/A // as really abstract. (This shouldn't happen, except during class 0N/A // evolution, but that's the logic of the checking.) However, if a 0N/A // supposedly abstract class or method suddenly becomes concrete, a 0N/A // dependency on it must fail. 0N/A // Checking old assertions at run-time (in the VM only): 0N/A // A returned klassOop is NULL if the dependency assertion is still 0N/A // valid. A non-NULL klassOop is a 'witness' to the assertion 0N/A // failure, a point in the class hierarchy where the assertion has 0N/A // been proven false. For example, if check_leaf_type returns 0N/A // non-NULL, the value is a subtype of the supposed leaf type. This 0N/A // witness value may be useful for logging the dependency failure. 0N/A // Note that, when a dependency fails, there may be several possible 0N/A // witnesses to the failure. The value returned from the check_foo 0N/A // method is chosen arbitrarily. 0N/A // The 'changes' value, if non-null, requests a limited spot-check 0N/A // near the indicated recent changes in the class hierarchy. 0N/A // It is used by DepStream::spot_check_dependency_at. 0N/A // Detecting possible new assertions: 0N/A // Create the encoding which will be stored in an nmethod. 0N/A // helper for encoding common context types as zero: 0N/A // Use this to iterate over an nmethod's dependency set. 0N/A // Works on new and old dependency sets. 0N/A // Dependencies::DepType dept; 0N/A // for (Dependencies::DepStream deps(nm); deps.next(); ) { 0N/A // The caller must be in the VM, since oops are not wrapped in handles. 0N/A // iteration variables: 0N/A // => _code? _code->oop_at(i): *_deps->_oop_recorder->handle_at(i) 0N/A // The point of the whole exercise: Is this dep is still OK? 0N/A // A lighter version: Checks only around recent changes in a class 0N/A // hierarchy. (See Universe::flush_dependents_on.) 0N/A // Log the current dependency to xtty or compilation log. 0N/A // Print the current dependency to tty. 0N/A// A class hierarchy change coming through the VM (under the Compile_lock). 0N/A// The change is structured as a single new type with any number of supers 0N/A// and implemented interface types. Other than the new type, any of the 0N/A// super types can be context types for a relevant dependency, which the 0N/A// new type could invalidate. 0N/A // each change set is rooted in exactly one new type (at present): 0N/A // notes the new type, marks it and all its super-types 0N/A // cleans up the marks 0N/A // involves_context(k) is true if k is new_type or any of the super types 0N/A // for (DepChange::ContextStream str(changes); str.next(); ) { 0N/A // klassOop k = str.klass(); 0N/A // iteration variables: 0N/A // start at the beginning: 0N/A // the nsv argument makes it safe to hold oops like _klass