deoptimization触发时，jit会同步阻塞线程并重建帧对象与栈状态，耗时5–20μs，远超解释执行（如binary_add仅80ns）；其本质是重置式重建而非降级，需dump寄存器、补写屏障、重置计数器，导致热点路径彻底失效。
Deoptimization 触发时，JIT 会立即切回解释执行
当 JIT 编译后的代码遇到无法满足的假设（如类型突变、闭包变量被外部修改、GC 移动对象导致指针失效），运行时必须中止当前机器码执行，跳转回解释器，并重建完整的帧对象和栈状态。这个过程不是“慢一点”，而是同步阻塞当前线程，且开销远超普通函数调用——典型耗时在 5–20μs 量级，而原生解释执行单条 BINARY_ADD 仅约 80ns。
常见触发现象包括：
-
recompile_reason: "freevar_mismatch"（闭包自由变量值或绑定关系变化） -
guard failure on type check（比如编译时假设obj.x是int，运行时却是str） -
deopt at _PyFrame_Push（帧对象被 GC 回收后又被 JIT 代码引用）
Python 中的 Deoptimization 不是“降级”，而是“重置式重建”
CPython 系列 JIT（如 Pyjion 或 3.15 实验分支）没有独立的 deopt stub 预留空间，每次逆优化都需：
- 从当前寄存器/栈中提取所有活跃 SSA 变量值
- 反向映射回 Python 对象并重新装入
PyFrameObject的f_localsplus数组 - 重置字节码计数器（
f_lasti）并跳转至对应co_code偏移
这意味着：哪怕只在循环末尾发生一次 deopt，整个循环体的 JIT 版本就彻底失效，后续所有迭代都走解释路径。你看到的“突然变慢”，其实是从第 N+1 次迭代开始，100% 解释执行，而非渐进退化。
如何确认是否遭遇了 Deoptimization 雪崩？
启用 JIT 日志是最直接手段。在 Python 3.15（或带 JIT 补丁的构建）中运行：
PYTHONJITLOG=1 python -c "def f(): return [i for i in range(100)]; print(len(f()))"
观察输出中是否高频出现：
deoptimize: function 'f', reason 'type_guard_failure'recompiling 'f' (deopt count: 3)discarding compiled version due to freevar change
若 deopt count 在单次函数调用内增长 >2，基本可判定存在不可收敛的逆优化循环——JIT 不断编译、不断失败、不断重建，CPU 时间大量消耗在元操作上，而非业务逻辑。
Deoptimization 成本常被低估的底层原因
它不只是“多几条指令”的问题。真实瓶颈藏在三处：
- 寄存器到内存的批量 dump：ARM64 上一次 deopt 可能触发 12+ 个
str xN, [sp, #offset]，破坏 CPU 流水线 - GC 写屏障重激活：JIT 代码绕过部分写屏障，deopt 后需补全对新生代对象的跟踪标记
- 热路径识别中断：一次 deopt 会让该函数的调用计数器归零，下次触发 JIT 编译需重新累积阈值（默认 1024 次）
所以，看似“只错一次”的类型误判，在高频小函数里可能演变成每毫秒一次的完整执行路径坍塌——这不是配置能调优的问题，而是设计边界本身在警告：某些动态模式根本不适合 JIT。
