Skip to content

Improving trace quality by tracking "fitness" and "exit quality" #146073

@markshannon

Description

@markshannon

Feature or enhancement

Proposal:

The performance of the JIT depends heavily on the quality of the traces that the front-end produces. If traces are too short, very long, overlap a lot, or drop into the interpreter too often, performance suffers.

To avoid those cases of poor performance, we should track two values during tracing:

  • The fitness of the current trace
  • The quality of the end of the trace as a point to stop the trace.

If fitness < exit_quality we should stop the trace.

Fitness:

Fitness should:

  • start high
  • be reduced by branches, how much depending on the bias of branch
  • be reduced (by quite a lot) by backward edges
  • be reduced a small amount by each instruction (to discourage excessively long traces)
  • start lower for non-branch side exits to reduce code replication

Exit quality

Exit quality should be high for:

  • The starting point of the trace (very high for this)
  • ENTER_EXECUTOR instructions
  • Merge points in the control flow graph (will need the bytecode compiler to generate this data)

Exit quality should be low for:

  • Specializable instructions

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.15new features, bugs and security fixesperformancePerformance or resource usagetopic-JITtype-featureA feature request or enhancement

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions