A type profile is information which summarizes the type of some value at some program point in the JVM. The summary is designed to allow the optimizing compiler to guess at future types at the same point in the program. In many cases, these profiles are necessary for attaining best code quality.
A program point is a specific instance of a bytecode. Not all bytecodes perform profiling.
The recorded type is the concrete class of the object. (I.e., it is the _klass object header field, of type Klass*.)
There is also an indication if nulls have been seen at the program point.
| Bytecode | Value |
|---|---|
| invokevirtual, invokeinterface | receiver |
| checkcast, instanceof | tested object |
| aastore | element value |
Primitive values are not currently profiled, but see bug 8015418. Non-receiver arguments and return values are not currently profiled, but see bug 6919064.
(FIXME: Move the following to a new page, MethodData.)
The interpreter and tier one compiled code collect type profiles. The profiles are crucial to later optimizing compilation. Tier one currently emulates the interpreter with respect to profiling.
A profile is a metadata structure of type MethodData. Each method has zero or one of them. The structure is laid out as a heterogeneous array which is sequenced in parallel with the bytecodes themselves. Only only a minority of bytecodes capture profile data, the overall profile block is often larger than the bytecodes themselves. Each element in the profile array captures information for one instance of a bytecode in the method. (These are the program points referred to above.)
A MethodData block is not created when its method is first loaded, but rather when the method is somehow noticed as relevant to execution (e.g., warm enough). Each profile applies to one bytecode method, and is affected by all executions of that method, from whatever caller. Each original instance of a relevant bytecode instruction (invokevirtual, checkcast, etc.) gets a ReceiverTypeData record in the MethodData block. Each record has a number (TypeProfileWidth, default 2) of rows, each of which contains a count and an exact object type. The record also has an overall count, which may differ from the sum of the individual counts.
Type profiles have two failure modes: First, a method might be compiled before its profile exists and is "mature", so that no stable conclusions can be drawn about operands in that method. Second, a method might be used from many different contexts with independent operand types (as with ArrayList.contains), so that the profile becomes "polluted" by many independent types. A polluted profile contains the first few (2) encountered types with low counts, and a high total count that signals that the ReceiverTypeData structure was too small.
Polluted profiles stem from the fact that a method (containing generically reusable code) has only one profile structure, but the method is reused from a variety of contexts, providing a variety of operand types.
Polluted profiles can be mitigated by a number of means, including:
- inlining with type information flowing from caller context
- inlining more than one case (UseBimorphicInlining)
- context-dependent split profiles (bug 8015416)
- hand inlining by the Java programmer (which is discouraged)
- generic type reification (when pollution comes from a type parameter; not implemented)
- other forms of online code splitting
Overview
Content Tools
ThemeBuilder