Skip to content

JIT should abandon rest of trace if we cannot optimize it #146297

Closed as not planned

Description

@Fidget-Spinner

Feature or enhancement

Proposal:

The JIT optimizer is now powerful enough that with it on, it pays for the JIT.

However, we seem to still be running code without optimizations. Specifically, when we hit out of space in the JIT optimizer, we just execute the unoptimized code. This is probably pretty bad for performance.

We should stop the trace at the last "safe" point, and _EXIT_TRACE there to allow the trace to grow naturally.

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

Linked PRs

Activity

  1. markshannon commented on Mar 23, 2026

    @markshannon
    Member

    Rather than handling the exotic case of running out of memory, we should make sure there is enough memory. A few assertions should be enough, rather than complex rewinding.

  2. Fidget-Spinner commented on Mar 23, 2026

    @Fidget-Spinner
    MemberAuthor

    Rather than handling the exotic case of running out of memory, we should make sure there is enough memory. A few assertions should be enough, rather than complex rewinding.

    This isn't exotic. It happens due to deep recursions in bm_generators taking up all the abstract stack. We should also extend it to handle contradictions (bottom) in the code.

  3. markshannon commented on Mar 24, 2026

    @markshannon
    Member

    Whatever it is, we shouldn't be getting into that state in the first place. The optimizer should be able to optimize whatever the front-end produces or, to put it another way, the front-end shouldn't be producing traces that the optimizer cannot handle.
    If we can't handle the deep recursion in the optimizer, we shouldn't be tracing that deep in the first place.

    Let's focus on making things robust by having invariants, not adding more code to handle corner cases that shouldn't exist.

  4. Fidget-Spinner commented on Mar 24, 2026

    @Fidget-Spinner
    MemberAuthor

    The front-end shouldn't be producing traces that the optimizer cannot handle.

    This is not always possible. For example, exception paths in the tracing interpreter naturally lead to contradictions in the optimizer. There are other things that I'm missing, but I'm pretty sure they exist.

    If we can't handle the deep recursion in the optimizer, we shouldn't be tracing that deep in the first place.

    Ok we should align the frontend with the optimizer's frame depth then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)topic-JITtype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions