InlineTools (Jikes RVM API)

Overview

Package

Class

Use

Tree

Serialized

Deprecated

Index

Help

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: NESTED | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

org.jikesrvm.compilers.opt.inlining
Class InlineTools

java.lang.Object
  org.jikesrvm.compilers.opt.inlining.InlineTools

All Implemented Interfaces:: OptConstants

Direct Known Subclasses:: DefaultInlineOracle

public abstract class InlineTools
extends Object
implements OptConstants
extends Object
implements OptConstants

This class provides some utilities that are useful for inlining.

Field Summary

Fields inherited from interface org.jikesrvm.compilers.opt.driver.OptConstants
`EPILOGUE_BCI, EPILOGUE_BLOCK_BCI, EXTANT_ANALYSIS_BCI, INSTRUMENTATION_BCI, MAYBE, METHOD_COUNTER_BCI, NO, OSR_PROLOGUE, PROLOGUE_BCI, PROLOGUE_BLOCK_BCI, RECTIFY_BCI, RUNTIME_SERVICES_BCI, SSA_SYNTH_BCI, SYNCHRONIZED_MONITORENTER_BCI, SYNCHRONIZED_MONITOREXIT_BCI, SYNTH_CATCH_BCI, SYNTH_LOOP_VERSIONING_BCI, UNKNOWN_BCI, YES`

Constructor Summary
`InlineTools()`

Method Summary
`static boolean`	`hasBody(RVMMethod callee)` Does the callee method have a body?
`static boolean`	`hasInlinePragma(RVMMethod callee, CompilationState state)` Should the callee method always be inlined?
`static boolean`	`hasNoInlinePragma(RVMMethod callee, CompilationState state)` Should the callee method be barred from ever being considered for inlining?
`static boolean`	`implementsInterface(Class<?> A, Class<?> B)` Does class `A` directly implement the interface `B`?
`static int`	`inlinedSizeEstimate(NormalMethod callee, CompilationState state)` Given the currently available information at the call site, what's our best guess on the inlined size of the callee?
`static boolean`	`isCurrentlyFinal(RVMMethod callee, boolean searchSubclasses)` Is the method CURRENTLY final (not overridden by any subclass)?
`static boolean`	`isForbiddenSpeculation(RVMMethod caller, RVMMethod callee)` Is it safe to speculatively inline the callee into the caller?
`static boolean`	`needsGuard(RVMMethod callee)` Does an inlined call to callee need a guard, to protect against a mispredicted dynamic dispatch?

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail

InlineTools

public InlineTools()

Method Detail

implementsInterface

public static boolean implementsInterface(Class<?> A,
                                          Class<?> B)

Does class A directly implement the interface B?

hasBody

public static boolean hasBody(RVMMethod callee)

Does the callee method have a body?

Parameters:: callee - The callee method
Returns:: true if it has bytecodes, false otherwise.

needsGuard

public static boolean needsGuard(RVMMethod callee)

Does an inlined call to callee need a guard, to protect against a mispredicted dynamic dispatch?

Parameters:: callee - the callee method

isCurrentlyFinal

public static boolean isCurrentlyFinal(RVMMethod callee,
                                       boolean searchSubclasses)

Is the method CURRENTLY final (not overridden by any subclass)? Note that this says nothing about whether or not the method will be overriden by future dynamically loaded classes.

inlinedSizeEstimate

public static int inlinedSizeEstimate(NormalMethod callee,
                                      CompilationState state)

Given the currently available information at the call site, what's our best guess on the inlined size of the callee?

Parameters:: callee - the method to be inlined; state - the compilation state decribing the call site where it is to be inlined
Returns:: an inlined size estimate (number of machine code instructions)

hasInlinePragma

public static boolean hasInlinePragma(RVMMethod callee,
                                      CompilationState state)

Should the callee method always be inlined? Usually this is becuase of a programmer directive (InlinePragma), but we also use this mechanism to hardwire a couple special cases.

Parameters:: callee - the method being considered for inlining; state - the compilation state of the caller.
Returns:: whether or not the callee should be unconditionally inlined.

hasNoInlinePragma

public static boolean hasNoInlinePragma(RVMMethod callee,
                                        CompilationState state)

Should the callee method be barred from ever being considered for inlining?

Parameters:: callee - the method being considered for inlining; state - the compilation state of the caller.
Returns:: whether or not the callee should be unconditionally barred from being inlined.

isForbiddenSpeculation

public static boolean isForbiddenSpeculation(RVMMethod caller,
                                             RVMMethod callee)

Is it safe to speculatively inline the callee into the caller? Some forms of speculative inlining are unsafe to apply to methods of the core virtual machine because if we are forced to invalidate the methods, we will be unable to compile their replacement method. The current test is overly conservative, but past attempts at defining a more precise set of "third rail" classes have always resulted in missing some (only to discover them later when Jikes RVM hangs or crashes.)

Parameters:: caller - the caller method; callee - the callee method
Returns:: Whether or not we are allowed to speculatively inline the callee into the caller.