You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
JIT should abandon rest of trace if we cannot optimize it #146297
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
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.
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.
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.
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.
Activity
markshannon commentedon Mar 23, 2026
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.
Fidget-Spinner commentedon Mar 23, 2026
This isn't exotic. It happens due to deep recursions in
bm_generatorstaking up all the abstract stack. We should also extend it to handle contradictions (bottom) in the code.markshannon commentedon Mar 24, 2026
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.
Fidget-Spinner commentedon Mar 24, 2026
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.
Ok we should align the frontend with the optimizer's frame depth then.