Package com.oracle.truffle.api.profiles

Class InlinedProfile

java.lang.Object
com.oracle.truffle.api.profiles.InlinedProfile
Direct Known Subclasses:
InlinedBranchProfile, InlinedByteValueProfile, InlinedConditionProfile, InlinedCountingConditionProfile, InlinedDoubleValueProfile, InlinedExactClassProfile, InlinedFloatValueProfile, InlinedIntValueProfile, InlinedLongValueProfile, InlinedLoopConditionProfile
public abstract class InlinedProfile extends Object
A profile is a Truffle utility class that uses the Truffle compiler directives to guard for and/or forward runtime information to the compiler. Whenever Truffle DSL can be used inlined profiles subclasses should be used instead of regular profile subclasses.

Usage: Inlined profiles are used using the Cached annotation in specialization methods. See the individual profile subclasses for further usage examples. Profiles are intended for local speculation only. For global speculations use assumptions instead.

Compilation: Some profiles like branch profiles do not induce additional overhead in compiled code. Others like value profiles might require a runtime check to verify their local speculation. Even if profiles do not induce direct overhead in compiled code it still might get invalidated as a result of using profiles. Invalidating profiles will result in the invalidation of compiled code. It is therefore essential to place these profiles in way that is neither too aggressive nor too conservative, ideally based on measurements in real world applications.

Footprint: Inlined versions of profiles have a significantly reduced memory footprint compared to their allocated counterparts, however they do rely on their usage being inlined to have the same performance characteristics. Whether profiling information can be forwarded to the compiler depends on the capabilities of the runtime system. If the runtime returns true in TruffleRuntime.isProfilingEnabled() then runtime information will get collected. This comes at at the cost of additional overhead and footprint in interpreted mode. Thats why the factory methods of profiles can return implementations where profiling is disabled. Using disabled profiles makes sense for runtimes that are unable to use the collected profiling information. Even runtime implementations that are able to use this information might decide to turn off profiling for benchmarking purposes.

Inlined profile subclasses:

Since:
23.0
See Also:

  • Method Details

    • disable

      public abstract void disable(Node node)
      Disables this profile by setting it to its generic state. After disabling it is guaranteed to never deoptimize on any invocation of a profile method.

      This method must not be called on compiled code paths. Note that disabling the profile will not invalidate existing compiled code that uses this profile.

      Since:
      23.0

    • reset

      public abstract void reset(Node node)
      Resets this profile to its uninitialized state. Has no effect if this profile is already in its uninitialized state or a disabled version of this profile is used.

      This method must not be called on compiled code paths. Note that disabling the profile will not invalidate existing compiled code that uses this profile.

      Since:
      23.0

    • toString

      public abstract String toString(Node node)
      Prints a string representation of this inlined profile given a target node.
      Since:
      23.0

    • toString

      public final String toString()
      Overrides:
      toString in class Object
      Since:
      23.0