public enum CEOptimization extends Enum<CEOptimization>
Enum Constant and Description |
---|
BoxNodeOptimization
BoxNodeOptimizationPhase is a compiler optimization for Java box operations. |
Canonicalization
CanonicalizerPhase is a compound optimization phase grouping together several
independent optimizations that are mostly "local" to a node and its directly connected nodes. |
ConditionalElimination
ConditionalEliminationPhase is a control-flow sensitive implementation of a
conditional elimination algorithm. |
DeadCodeElimination
DeadCodeEliminationPhase tries to remove unused (i.e., "dead") code from a program. |
DeoptimizationGrouping
DeoptimizationGroupingPhase tries to reduce the meta-data the compiler needs to
preserve in the generated machine code for deoptimization purposes. |
DeoptimizeToGuard
ConvertDeoptimizeToGuardPhase analyzes the control flow graph of a program and tries
to find patterns of the form |
ExpressionReassociation
ReassociationPhase implements expression reassociation. |
FloatingReads
FloatingReadPhase rewrites fixed memory read nodes to floating read nodes that can
move more freely (see CEOptimization.InstructionScheduling ). |
FullLoopUnrolling
LoopFullUnrollPhase is a special form of loop unrolling that processes loops with a
constant number of iterations. |
Inlining
InliningPhase is Graal CE's implementation of a traditional inlining algorithm. |
InstructionScheduling
SchedulePhase is Graal's implementation of an instruction scheduling algorithm for
the compiler IR. |
LockElimination
LockEliminationPhase tries to reduce Java monitor enter/exit overhead of an
application. |
LoopPeeling
LoopPeelingPhase is an optimization that moves first or last loop iterations outside
the loop. |
LoopPredication
LoopPredicationPhase performs a more limited form of hoisting array bounds checks out
of loops than CEOptimization.SpeculativeGuardMovement . |
LoopUnswitching
LoopUnswitchingPhase is a traditional compiler optimization dealing with loops with
loop invariant control flow (conditions) inside a loop's body. |
PartialEscapeAnanylsis
PartialEscapePhase is a control flow sensitive algorithm that can replace object and
array allocation with use of stack slots and registers in the hot parts of a graph. |
PartialLoopUnrolling
LoopPartialUnrollPhase is a compiler optimization unrolling the body of a loop
multiple times to improve instruction-level parallelism, reduce the loop control overhead and
enable other optimizations. |
ReadElimination
ReadEliminationPhase tries to remove redundant memory access operations (e.g.,
successive reads of the same Java field are redundant). |
SafepointElimination
LoopSafepointEliminationPhase tries to reduce the number of safepoint checks in the
generated machine code. |
SpeculativeGuardMovement
SpeculativeGuardMovementPhase tries to move a loop invariant guard (e.g., an array
bounds check) inside a loop to outside of the loop. |
TrappingNullChecks
UseTrappingNullChecksPhase exploits modern processors abilities to throw signals for
invalid memory accesses to remove explicit null check operations and replace them with
implicit checks. |
Modifier and Type | Method and Description |
---|---|
static CEOptimization |
valueOf(String name)
Returns the enum constant of this type with the specified name.
|
static CEOptimization[] |
values()
Returns an array containing the constants of this enum type, in
the order they are declared.
|
public static final CEOptimization Canonicalization
CanonicalizerPhase
is a compound optimization phase grouping together several
independent optimizations that are mostly "local" to a node and its directly connected nodes.
Optimizations include constant folding, strength reduction, algebraic simplifications and so
on.
This phase is unconditionally enabled.public static final CEOptimization Inlining
InliningPhase
is Graal CE's implementation of a traditional inlining algorithm.
This phase is enabled by default and can be disabled with HighTier.Options.Inline
.public static final CEOptimization DeadCodeElimination
DeadCodeEliminationPhase
tries to remove unused (i.e., "dead") code from a program.
Program code is considered dead if it is proven to be never executed at runtime. This often
arises as the result of preceding optimizations.
This phase is unconditionally enabled.public static final CEOptimization DeoptimizeToGuard
ConvertDeoptimizeToGuardPhase
analyzes the control flow graph of a program and tries
to find patterns of the form
if (...) deoptimizeIt rewrites such a pattern to a single IR guard node that can be optimized better than fixed control flow. This can improve program performance since guards can move freely around in the program and be scheduled at points which have a lower execution probability resulting in less instructions being executed at runtime. This phase is enabled by default and can be disabled with
GraalOptions.OptConvertDeoptsToGuards
.public static final CEOptimization ConditionalElimination
ConditionalEliminationPhase
is a control-flow sensitive implementation of a
conditional elimination algorithm. It combines flow-sensitive type and value information and
removes conditional operations for which the associated condition can be proven true
or false
.
This phase is enabled by default and can be disabled with
GraalOptions.ConditionalElimination
.public static final CEOptimization InstructionScheduling
SchedulePhase
is Graal's implementation of an instruction scheduling algorithm for
the compiler IR. Graal
IR is a graph-based intermediate representation loosely based on the idea of the
"sea-of-nodes" IR. In the IR, side-effect free operations are represented with so-called
"floating" nodes that can freely move around in the compiler IR until code emission where the
final position of a node in the generated program is solely dependent on its input (data
dependencies) and usages.
This phase is unconditionally enabled (it's required for correct code generation).public static final CEOptimization FloatingReads
FloatingReadPhase
rewrites fixed memory read nodes to floating read nodes that can
move more freely (see CEOptimization.InstructionScheduling
). It builds a memory graph which allows better optimization of memory related instructions.
This phase is enabled by default and can be disabled with
GraalOptions.OptFloatingReads
.public static final CEOptimization ReadElimination
ReadEliminationPhase
tries to remove redundant memory access operations (e.g.,
successive reads of the same Java field are redundant). Its uses a control-flow sensitive
analysis.
This phase is enabled by default and can be disabled with
GraalOptions.OptReadElimination
.public static final CEOptimization PartialEscapeAnanylsis
PartialEscapePhase
is a control flow sensitive algorithm that can replace object and
array allocation with use of stack slots and registers in the hot parts of a graph. Unlike
non-partial escape analysis, it can perform this transformation by allowing an object
allocation to be deferred to cold paths that exit the compilation unit.
This optimization has a non-trivial impact on compilation time and so might be worth
disabling for workloads that do not perform much allocation.
Object allocations are expensive thus partial escape analysis can greatly improve performance
of an application by reducing the number of allocations. This reduces interaction with the
memory manager on the allocation path and also reduces work done during garbage collection.
This phase is enabled by default and can be disabled with
GraalOptions.PartialEscapeAnalysis
.public static final CEOptimization LockElimination
LockEliminationPhase
tries to reduce Java monitor enter/exit overhead of an
application. Java synchronized
blocks mark critical regions which can only be entered
if a thread acquires an object monitor (enter operation). A monitor is held until the region
is exited (monitor exit). Lock elimination (also known as lock coarsening) tries to merge
adjacent synchronized regions into larger ones by removing enters that are directly followed
by exits on the same locked object. It thus removes redundant unlock-lock operations.
This phase is unconditionally enabled.public static final CEOptimization SafepointElimination
LoopSafepointEliminationPhase
tries to reduce the number of safepoint checks in the
generated machine code. Safepoints in Java are program locations where mutator threads
(application threads) are at a well defined point with respect to the Java heap. This means
at a safepoint the GC can safely manipulate the Java heap. Typical safepoint operations are
garbage collections, class redefinition, lock unbiasing, and monitor deflation. As the
safepoint protocol is a cooperative mechanism, it requires code generated by the compiler to
periodically poll (i.e., read) a well known memory location. These polls can incur
performance overheads in very tight loops. Thus, Graal removes safepoint polls in loops
heuristically to improve performance.
This phase is unconditionally enabled.public static final CEOptimization ExpressionReassociation
ReassociationPhase
implements expression reassociation. It re-orders operations and
their operands to create more potential for constant folding and loop invariant code motion.
This phase is enabled by default and can be disabled with
GraalOptions.ReassociateExpressions
.public static final CEOptimization DeoptimizationGrouping
DeoptimizationGroupingPhase
tries to reduce the meta-data the compiler needs to
preserve in the generated machine code for deoptimization purposes. This optimization can
reduce the size of the generated machine code at runtime.
This phase is enabled by default and can be disabled with
GraalOptions.OptDeoptimizationGrouping
.public static final CEOptimization TrappingNullChecks
UseTrappingNullChecksPhase
exploits modern processors abilities to throw signals for
invalid memory accesses to remove explicit null check operations and replace them with
implicit checks. This optimization removes explicit null checks. If a null memory location is
accessed by the generated code, hardware memory protection will raise a SIGSEGV signal. The
VM catches this signal, maps it to the program location of an implicit null check and throws
a regular NullPointerException
at that location. This optimization can improve the
performance of generated code by removing an explicit null check before memory reads.
This phase is unconditionally enabled.public static final CEOptimization FullLoopUnrolling
LoopFullUnrollPhase
is a special form of loop unrolling that processes loops with a
constant number of iterations. Based on heuristics which include but are not exclusively
based on the number of iterations, this phase will either completely unroll a loop or not
transform it at all. That is, it is an "all or nothing" phase.
Unrolling a loop can improve performance by removing the loop control and jump overhead. It
also produces larger basic blocks and thus more scope for other optimizations to apply. Full
loop unrolling will generally increase code size which can decrease performance. For this
reason, the decision of whether or not it is applied for a given loop takes into account
factors beyond the constant iteration count such as current code size.
This phase is enabled by default and can be disabled with GraalOptions.FullUnroll
.public static final CEOptimization SpeculativeGuardMovement
SpeculativeGuardMovementPhase
tries to move a loop invariant guard (e.g., an array
bounds check) inside a loop to outside of the loop. This can improve performance since the
body of the loop is simplified.
This phase is enabled by default and can be disabled with
GraalOptions.SpeculativeGuardMovement
.public static final CEOptimization LoopPredication
LoopPredicationPhase
performs a more limited form of hoisting array bounds checks out
of loops than CEOptimization.SpeculativeGuardMovement
.
If CEOptimization.SpeculativeGuardMovement
is disabled, this phase is enabled by default and can be
disabled with GraalOptions.LoopPredication
.public static final CEOptimization LoopPeeling
LoopPeelingPhase
is an optimization that moves first or last loop iterations outside
the loop. This process of moving loop iterations is called "peeling". This can improve
performance of the generated code when the peeled iterations have complex logic that is
absent from the unpeeled iterations.
This phase is enabled by default and can be disabled with GraalOptions.LoopPeeling
.public static final CEOptimization LoopUnswitching
LoopUnswitchingPhase
is a traditional compiler optimization dealing with loops with
loop invariant control flow (conditions) inside a loop's body. It "unswitches" a loop, ie.
pulls the invariant condition outside and duplicates a loop for the respective branches of
the invariant condition. This can improve performance since less instructions are evaluated
inside the loop's body.
This phase is enabled by default and can be disabled with GraalOptions.LoopUnswitch
.public static final CEOptimization PartialLoopUnrolling
LoopPartialUnrollPhase
is a compiler optimization unrolling the body of a loop
multiple times to improve instruction-level parallelism, reduce the loop control overhead and
enable other optimizations.
This phase is enabled by default and can be disabled with GraalOptions.PartialUnroll
.public static final CEOptimization BoxNodeOptimization
BoxNodeOptimizationPhase
is a compiler optimization for Java box operations. The
phase tries to re-use dominating boxed/unboxed values to avoid repetitive boxing while it
respects the caching behavior specified by Integer.valueOf(int)
.
This phase is enabled by default.public static CEOptimization[] values()
public static CEOptimization valueOf(String name)
name
- the name of the enum constant to be returned.IllegalArgumentException
- if this enum type has no constant with the specified nameNullPointerException
- if the argument is null