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