2099N/A * Copyright (c) 2000, 2011, Oracle and/or its affiliates. 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. 1472N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A// The MethodData object collects counts and other profile information 0N/A// during zeroth-tier (interpretive) and first-tier execution. 0N/A// The profile is used later by compilation heuristics. Some heuristics 0N/A// enable use of aggressive (or "heroic") optimizations. An aggressive 0N/A// optimization often has a down-side, a corner case that it handles 0N/A// poorly, but which is thought to be rare. The profile provides 0N/A// evidence of this rarity for a given method or even BCI. It allows 0N/A// the compiler to back out of the optimization at places where it 0N/A// has historically been a poor choice. Other heuristics try to use 0N/A// specific information gathered about types observed at a given site. 0N/A// All data in the profile is approximate. It is expected to be accurate 0N/A// on the whole, but the system expects occasional inaccuraces, due to 0N/A// counter overflow, multiprocessor races during data collection, space 0N/A// limitations, missing MDO blocks, etc. Bad or missing data will degrade 0N/A// optimization quality but will not affect correctness. Also, each MDO 0N/A// is marked with its birth-date ("creation_mileage") which can be used 0N/A// to assess the quality ("maturity") of its data. 0N/A// Short (<32-bit) counters are designed to overflow to a known "saturated" 0N/A// state. Also, certain recorded per-BCI events are given one-bit counters 0N/A// which overflow to a saturated state which applied to all counters at 0N/A// that BCI. In other words, there is a small lattice which approximates 0N/A// the ideal of an infinite-precision counter for each event at each BCI, 0N/A// and the lattice quickly "bottoms out" in a state where all counters 0N/A// are taken to be indefinitely large. 0N/A// The reader will find many data races in profile gathering code, starting 0N/A// with invocation counter incrementation. None of these races harm correct 0N/A// execution of the compiled code. 0N/A// Overlay for generic profiling data. 0N/A // Every data layout begins with a header. This header 0N/A // of the data, 4 bits of flags, which can be used in any way, 0N/A // and a bci, which is used to tie this piece of data to a 0N/A // specific bci in the bytecodes. 0N/A // The data layout has an arbitrary number of cells, each sized 0N/A // to accomodate a pointer or an integer. 0N/A // Some types of data layouts need a length field. 0N/A // The _struct._flags word is formatted as [trap_state:4 | flags:4]. 0N/A // The trap state breaks down further as [recompile:1 | reason:3]. 0N/A // See Deoptimization::trap_state_reason for an assert that 0N/A // trap_bits is big enough to hold reasons < Reason_RECORDED_LIMIT. 0N/A // The trap_state is collected only if ProfileTraps is true. 0N/A trap_bits =
1+
3,
// 3: enough to distinguish [0..Reason_RECORDED_LIMIT]. 0N/A // Return a few bits of trap state. Range is [0..trap_mask]. 0N/A // The state tells if traps with zero, one, or many reasons have occurred. 0N/A // It also tells whether zero or many recompilations have occurred. 0N/A // The associated trap histogram in the MDO itself tells whether 0N/A // traps are common or not. If a BCI shows that a trap X has 0N/A // occurred, and the MDO shows N occurrences of X, we make the 0N/A // simplifying assumption that all N occurrences can be blamed 0N/A // Low-level support for code generation. 0N/A // Return a value which, when or-ed as a byte into _flags, sets the flag. 0N/A // Return a value which, when or-ed as a word into _header, sets the flag. 0N/A// ProfileData class hierarchy 0N/A// A ProfileData object is created to refer to a section of profiling 0N/A// data in a structured way. 0N/A // This is a pointer to a section of profiling data. 0N/A // How many cells are in this? 0N/A // Return the size of this data. 0N/A // Low-level accessors for underlying data 0N/A // two convenient imports for use by subclasses: 0N/A // Constructor for invalid ProfileData. 0N/A // Subclass specific initialization 0N/A // Parallel old support 0N/A // CI translation: ProfileData can represent both MethodDataOop data 0N/A // as well as CIMethodData data. This function is provided for translating 0N/A // an oop in a ProfileData to the ci equivalent. Generally speaking, 0N/A // most ProfileData don't require any translation, so we provide the null 0N/A // translation here, and the required translators are in the ci subclasses. 0N/A// A BitData holds a flag or two in its header. 0N/A // The null_seen flag bit is specially known to the interpreter. 0N/A // Consulting it allows the compiler to avoid setting up null_check traps. 0N/A // Code generation support 0N/A// A CounterData corresponds to a simple counter. 0N/A // Code generation support 0N/A// A JumpData is used to access profiling information for a direct 0N/A// branch. It is a counter, used for counting the number of branches, 0N/A// plus a data displacement, used for realigning the data pointer to 0N/A// the corresponding target bci. 0N/A // Saturating counter 0N/A // Did we wrap? Will compiler screw us?? 0N/A // Code generation support 0N/A // Specific initialization. 0N/A// A ReceiverTypeData is used to access profiling information about a 0N/A// dynamic type check. It consists of a counter which counts the total times 0N/A// that the check is reached, and a series of (klassOop, count) pairs 0N/A// which are used to store a type profile for the receiver of the check. 0N/A // Get the receiver at row. The 'unchecked' version is needed by parallel old 0N/A // gc; it does not assert the receiver is a klass. During compaction of the 0N/A // perm gen, the klass may already have moved, so the is_klass() predicate 0N/A // would fail. The 'normal' version should be used whenever possible. 1251N/A // Clear total count - indicator of polymorphic call site. 1251N/A // The site may look like as monomorphic after that but 1251N/A // it allow to have more accurate profiling information because 1251N/A // there was execution phase change since klasses were unloaded. 1251N/A // If the site is still polymorphic then MDO will be updated 1251N/A // to reflect it. But it could be the case that the site becomes 1251N/A // only bimorphic. Then keeping total count not 0 will be wrong. 1251N/A // Even if we use monomorphic (when it is not) for compilation 1251N/A // we will only have trap, deoptimization and recompile again 1251N/A // with updated MDO after executing method in Interpreter. 1251N/A // An additional receiver will be recorded in the cleaned row 1251N/A // during next call execution. 1251N/A // Note: our profiling logic works with empty rows in any slot. 1251N/A // We do sorting a profiling info (ciCallProfile) for compilation. 0N/A // Code generation support 0N/A // Parallel old support 0N/A// A VirtualCallData is used to access profiling information about a 0N/A// virtual call. For now, it has nothing more than a ReceiverTypeData. 0N/A // At this point we could add more profile state, e.g., for arguments. 0N/A // But for now it's the same size as the base record type. 0N/A// A RetData is used to access profiling information for a ret bytecode. 0N/A// It is composed of a count of the number of times that the ret has 0N/A// been executed, followed by a series of triples of the form 0N/A// (bci, count, di) which count the number of times that some bci was the 0N/A// target of the ret and cache a corresponding data displacement. 0N/A // 'release' when setting the bci acts as a valid flag for other 0N/A // threads wrt bci_count and bci_displacement. 0N/A no_bci = -
1 // value of bci when bci1/2 are not in use. 0N/A // Interpreter Runtime support 0N/A // Code generation support 0N/A // Specific initialization. 0N/A// A BranchData is used to access profiling data for a two-way branch. 0N/A// It consists of taken and not_taken counts as well as a data displacement 0N/A// for the taken case. 0N/A // Did we wrap? Will compiler screw us?? 0N/A // Code generation support 0N/A // Specific initialization. 0N/A// A ArrayData is a base class for accessing profiling data which does 0N/A// not have a statically known size. It consists of an array length 0N/A// and an array start. 0N/A // Code generation support for subclasses. 0N/A // Code generation support 0N/A// A MultiBranchData is used to access profiling information for 0N/A// a multi-way branch (*switch bytecodes). It consists of a series 0N/A// of (count, displacement) pairs, which count the number of times each 0N/A// case was taken and specify the data displacment for each branch target. 0N/A // Code generation support 0N/A // Specific initialization. 0N/A// A methodDataOop holds information which has been collected about 0N/A// a method. Its layout looks like this: 0N/A// ----------------------------- 0N/A// ----------------------------- 0N/A// | size of the methodDataOop | 0N/A// ----------------------------- 0N/A// | Data entries... | 0N/A// | (variable size) | 0N/A// ----------------------------- 0N/A// The data entry area is a heterogeneous array of DataLayouts. Each 0N/A// DataLayout in the array corresponds to a specific bytecode in the 0N/A// method. The entries in the array are sorted by the corresponding 0N/A// bytecode. Access to the data is via resource-allocated ProfileData, 0N/A// which point to the underlying blocks of DataLayout structures. 0N/A// During interpretation, if profiling in enabled, the interpreter 0N/A// maintains a method data pointer (mdp), which points at the entry 0N/A// in the array corresponding to the current bci. In the course of 0N/A// intepretation, when a bytecode is encountered that has profile data 0N/A// associated with it, the entry pointed to by mdp is updated, then the 0N/A// mdp is adjusted to point to the next appropriate DataLayout. If mdp 0N/A// is NULL to begin with, the interpreter assumes that the current method 0N/A// is not (yet) being profiled. 0N/A// In methodDataOop parlance, "dp" is a "data pointer", the actual address 0N/A// of a DataLayout element. A "di" is a "data index", the offset in bytes 0N/A// from the base of the data entry array. A "displacement" is the byte offset 0N/A// in certain ProfileData objects that indicate the amount the mdp must be 0N/A// adjusted in the event of a change in control flow. 0N/A // Back pointer to the methodOop 0N/A // Size of this oop in bytes 0N/A // Cached hint for bci_to_dp and bci_to_data 0N/A // Whole-method sticky bits and flags 0N/A };
// Public flag values 0N/A // Support for interprocedural escape analysis, from Thomas Kotzmann. 1703N/A // How many invocations has this MDO seen? 1703N/A // These counters are used to determine the exact age of MDO. 1703N/A // We need those because in tiered a method can be concurrently 1703N/A // executed at different levels. 2124N/A // Counter values at the time profiling started. 1703N/A // Number of loops and blocks is computed when compiling the first 1703N/A // time with C1. It is used to determine if method is trivial. 1703N/A // Highest compile level this method has ever seen. 1703N/A // Does this method contain anything worth profiling? 0N/A // Size of _data array in bytes. (Excludes header and extra_data fields.) 0N/A // Beginning of the data entries 0N/A // Helper for size computation 0N/A // Helper for initialization 0N/A // Initialize an individual data segment. Returns the size of 0N/A // the segment in bytes. 0N/A // Helper for data_at 0N/A // Give each of the data entries a chance to perform specific 0N/A // data initialization. 0N/A // avoid SEGV on this edge case 0N/A // What is the index of the first data entry? 0N/A // Find or create an extra ProfileData: 45N/A // return the argument info cell 0N/A // Compute the size of a methodDataOop before it is created. 0N/A // Determine if a given bytecode can have profile information. 0N/A // Perform initialization of a new methodDataOop 0N/A bool is_mature()
const;
// consult mileage and ProfileMaturityPercentage 0N/A // Support for interprocedural escape analysis, from Thomas Kotzmann. 0N/A // Location and size of data area 0N/A // Get the data at an arbitrary (sort of) data index. 0N/A // Walk through the data in order. 0N/A // Convert a dp (data pointer) to a di (data index). 0N/A // Get the data at an arbitrary bci, or NULL if there is none. 0N/A // Same, but try to create an extra_data record if one is needed: 0N/A // Add a handful of extra data records, for trap tracking. 0N/A // Return (uint)-1 for overflow. 0N/A // Count another trap, anywhere in this method. 0N/A // Could not represent the count in the histogram. 0N/A // Support for code generation 0N/A // printing support for method data 1879N/A#
endif // SHARE_VM_OOPS_METHODDATAOOP_HPP