Trace recording JIT

[Fidget-Spinner]

This issue tracks progress of changing the JIT from one that projects traces to one that records them.

Linked PRs

• gh-139109: Dynamic opcode targets #139111

[markshannon]

Just to flesh this out a bit:

Motivation

Currently we project traces from the initial hotspot, but there are a number of places in the projection where we would benefit from having live values as well as the statistical information gathered by the interpreter.

We can combine the information from live values with the statistical information to give us a trace that should, in theory, be better than from either pure trace recording or from projection.

Design

Confidence

As a trace gets longer, it is less likely that a future execution will remain on trace. Our estimate of that future likelihood is our "confidence" in the trace at that point. All traces start with confidence at 100%, but that confidence drops with each guard in the trace.

The trace recording interpreter

The trace recording interpreter operates exactly as the normal tier 1 interpreter, while recording the instructions executed.

While trace recording we should maintain a confidence level, but this confidence level will not be as accurate as the optimizer can provide. Since the optimizer might be more confident, and we cannot optimize beyond the end of the recorded trace, the confidence limit for recording should be lower than for the final trace.

Possible implementations

We can:

1. Record the trace at the bytecode level, then lower to micro-ops as a separate pass
2. Lower as we go. This is more complicated, but may be faster as it saves recording the bytecode.

I think we should start with 1. We can move to 2. later without impacting the rest of the JIT.

To avoid doubling the size of the interpreter, each recording opcode implementation should call a common recording function then jump to the normal implementation of that opcode.

However, some specialized instructions could "deopt", executing the non-specialized instruction. This would result in a misleading trace, so we might want to somehow force re-specialization in that case. It is not obvious how to do that without duplicating all specialized instructions. We could force re-specialization of all instructions, that might be slow.