|
|
Java example source code file (dependencies.hpp)
This example Java source code file (dependencies.hpp) is included in the alvinalexander.com
"Java Source Code
Warehouse" project. The intent of this project is to help you "Learn
Java by Example" TM.
Learn more about this Java project at its project page.
The dependencies.hpp Java example source code
/*
* Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation.
*
* This code is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License version
* 2 along with this work; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
* or visit www.oracle.com if you need additional information or have any
* questions.
*
*/
#ifndef SHARE_VM_CODE_DEPENDENCIES_HPP
#define SHARE_VM_CODE_DEPENDENCIES_HPP
#include "ci/ciCallSite.hpp"
#include "ci/ciKlass.hpp"
#include "ci/ciMethodHandle.hpp"
#include "classfile/systemDictionary.hpp"
#include "code/compressedStream.hpp"
#include "code/nmethod.hpp"
#include "utilities/growableArray.hpp"
//** Dependencies represent assertions (approximate invariants) within
// the runtime system, e.g. class hierarchy changes. An example is an
// assertion that a given method is not overridden; another example is
// that a type has only one concrete subtype. Compiled code which
// relies on such assertions must be discarded if they are overturned
// by changes in the runtime system. We can think of these assertions
// as approximate invariants, because we expect them to be overturned
// very infrequently. We are willing to perform expensive recovery
// operations when they are overturned. The benefit, of course, is
// performing optimistic optimizations (!) on the object code.
//
// Changes in the class hierarchy due to dynamic linking or
// class evolution can violate dependencies. There is enough
// indexing between classes and nmethods to make dependency
// checking reasonably efficient.
class ciEnv;
class nmethod;
class OopRecorder;
class xmlStream;
class CompileLog;
class DepChange;
class KlassDepChange;
class CallSiteDepChange;
class No_Safepoint_Verifier;
class Dependencies: public ResourceObj {
public:
// Note: In the comments on dependency types, most uses of the terms
// subtype and supertype are used in a "non-strict" or "inclusive"
// sense, and are starred to remind the reader of this fact.
// Strict uses of the terms use the word "proper".
//
// Specifically, every class is its own subtype* and supertype*.
// (This trick is easier than continually saying things like "Y is a
// subtype of X or X itself".)
//
// Sometimes we write X > Y to mean X is a proper supertype of Y.
// The notation X > {Y, Z} means X has proper subtypes Y, Z.
// The notation X.m > Y means that Y inherits m from X, while
// X.m > Y.m means Y overrides X.m. A star denotes abstractness,
// as *I > A, meaning (abstract) interface I is a super type of A,
// or A.*m > B.m, meaning B.m implements abstract method A.m.
//
// In this module, the terms "subtype" and "supertype" refer to
// Java-level reference type conversions, as detected by
// "instanceof" and performed by "checkcast" operations. The method
// Klass::is_subtype_of tests these relations. Note that "subtype"
// is richer than "subclass" (as tested by Klass::is_subclass_of),
// since it takes account of relations involving interface and array
// types.
//
// To avoid needless complexity, dependencies involving array types
// are not accepted. If you need to make an assertion about an
// array type, make the assertion about its corresponding element
// types. Any assertion that might change about an array type can
// be converted to an assertion about its element type.
//
// Most dependencies are evaluated over a "context type" CX, which
// stands for the set Subtypes(CX) of every Java type that is a subtype*
// of CX. When the system loads a new class or interface N, it is
// responsible for re-evaluating changed dependencies whose context
// type now includes N, that is, all super types of N.
//
enum DepType {
end_marker = 0,
// An 'evol' dependency simply notes that the contents of the
// method were used. If it evolves (is replaced), the nmethod
// must be recompiled. No other dependencies are implied.
evol_method,
FIRST_TYPE = evol_method,
// A context type CX is a leaf it if has no proper subtype.
leaf_type,
// An abstract class CX has exactly one concrete subtype CC.
abstract_with_unique_concrete_subtype,
// The type CX is purely abstract, with no concrete subtype* at all.
abstract_with_no_concrete_subtype,
// The concrete CX is free of concrete proper subtypes.
concrete_with_no_concrete_subtype,
// Given a method M1 and a context class CX, the set MM(CX, M1) of
// "concrete matching methods" in CX of M1 is the set of every
// concrete M2 for which it is possible to create an invokevirtual
// or invokeinterface call site that can reach either M1 or M2.
// That is, M1 and M2 share a name, signature, and vtable index.
// We wish to notice when the set MM(CX, M1) is just {M1}, or
// perhaps a set of two {M1,M2}, and issue dependencies on this.
// The set MM(CX, M1) can be computed by starting with any matching
// concrete M2 that is inherited into CX, and then walking the
// 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
// than {M1}.
unique_concrete_method, // one unique concrete method under CX
// 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.
abstract_with_exclusive_concrete_subtypes_2,
// This dependency asserts that MM(CX, M1) is no greater than {M1,M2}.
exclusive_concrete_methods_2,
// This dependency asserts that no instances of class or it's
// subclasses require finalization registration.
no_finalizable_subclasses,
// This dependency asserts when the CallSite.target value changed.
call_site_target_value,
TYPE_LIMIT
};
enum {
LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1<ident] & (1<
Other Java examples (source code examples)
Here is a short list of links related to this Java dependencies.hpp source code file:
|
The search page
Other Java source code examples at this package level
Click here to learn more about this project
