在即时编译（JIT）系统中，缓存失效策略直接决定运行时编译的性能开销与内存占用。CJIT（Continuous JIT）模式将 LLVM IR 持久化缓存在内存或磁盘上，复用已编译的机器码仅在输入发生变化时触发重新编译。理解 IR 缓存失效机制的细粒度实现差异，是优化运行时编译吞吐量的关键所在。
缓存失效的触发条件
LLVM IR 缓存失效并非单一事件，而是由多个维度共同决定。当任何影响编译正确性或优化效果的前提条件发生变化时，之前生成的机器码必须被丢弃并重新编译。核心触发因素包括以下几类：
目标平台变化是强制失效的首要场景。若主机 CPU 的特性集合发生改变 —— 例如从 AVX2 升级到 AVX512，或目标三元组（triple）从 x86_64-pc-linux-gnu 切换到 aarch64-unknown-linux-gnueabihf—— 先前生成的代码在语义上可能不再正确，在性能上必然不再最优。此类变化通常由运行时检测到硬件能力变化或用户显式切换目标平台时触发。
IR 内容的突变同样需要失效。当加载的模块或其引用的元数据发生变化时 —— 函数属性调整、链接类型改变、内联汇编内容修改 —— 缓存的机器码与当前 IR 之间的对应关系被破坏。此外，若优化管线本身发生变化，例如从 O2 切换到 O3，或启用了不同的 pass 集合，原有缓存也无法反映新优化策略的效果。
外部依赖的变更构成了第三类触发条件。IR 所依赖的外部库函数、内在函数（intrinsics）或运行时回调地址发生变化时，必须重新编译以保证调用约定的正确性。在支持去优化（deoptimization）或栈上替换（OSR）的运行时环境中，当执行路径发生显著变化导致先前编译的代码不再适用时，也需要触发失效。
基于哈希的失效策略
哈希失效是实现缓存键（cache key）最常用且最有效的方法。其核心思想是为每个 IR 模块状态计算加密哈希值，将该哈希作为缓存查找的唯一标识。当后续编译请求到来时，重新计算哈希并与缓存中存储的哈希比对 —— 若哈希值不同，则必然存在影响编译结果的前提条件变化，此时触发失效并重新编译。
构建有效的哈希需要覆盖所有影响编译结果的状态维度。IR 内容本身是最基础的组成部分，但仅包含 IR 文本远远不够。完整的哈希应当纳入模块级元数据（如链接模式、属性标记）、目标三元组与数据布局（data layout）、活跃的函数属性与内联提示、使用的内在函数集合，以及 JIT 配置参数（优化级别、代码模型等）。任何一个维度的差异都应导致哈希值的改变。
在工程实践中，推荐采用 SHA-256 或更高强度的哈希算法。计算频率取决于缓存查找的粒度：对于高频率的函数级编译请求，可以在模块入口处计算整体哈希后复用；对于需要细粒度控制场景，可在函数级别分别计算哈希，仅失效发生变化的函数而保留其他函数的缓存。哈希计算本身应当被视为编译流水线的必要成本，其耗时通常在数百微秒级别，对于延迟敏感的场景可考虑使用 xxHash 等非加密哈希以换取更快的计算速度。
版本化缓存的实现路径
版本化缓存与哈希失效思路相近，但在实现上采用显式版本号管理。每个模块或缓存条目关联一个版本标签，当发生前述任何失效触发条件时，递增版本号并以新版本作为缓存键。版本号可以存储在进程内映射表或持久化存储中，结合操作系统级别的键值检索机制获取当前版本对应的缓存机器码。
版本化策略的优势在于调试与可观测性。显式的版本号便于日志记录和问题诊断 —— 当发现性能回退时，可通过版本号快速定位是否使用了错误的缓存版本。相比之下，哈希失效仅能通过哈希值本身进行追溯，排查问题时需要额外的上下文关联。版本号也可以携带语义信息，例如使用主版本号标记目标平台变化，次版本号标记 IR 内容变化，修订号标记优化管线调整，从而在不查询日志的情况下判断失效根因。
实现版本化缓存时需要注意并发安全问题。在多线程环境下，某个线程触发版本号递增的同时，其他线程可能正在使用旧版本的缓存条目。常见解决方案包括 Copy-on-Write 策略 —— 在递增版本号前复制当前缓存内容，确保旧版本请求仍能完成 —— 或采用无锁数据结构（如基于原子操作的并发哈希表）管理多版本并存的情况。ORC JIT 提供的 ThreadSafeModule 封装即是为此类并发场景设计，它在模块级别协调多线程的访问与失效操作。
细粒度失效与缓存分层
粗粒度的全局失效会导致不必要的重复编译开销。当仅有少数函数发生变更时，清空整个缓存意味着所有已编译的机器码都被丢弃，即使其中大部分仍然有效。细粒度失效策略通过在函数或 pass 级别追踪依赖关系，仅失效受影响的缓存条目。
实现细粒度失效需要构建依赖图。每个 IR 函数可以视为一个节点，函数间的调用关系、数据依赖关系构成边。当某个函数发生变更时，沿着依赖图向外传播失效信号，标记所有受影响的后续函数。与函数级别的粗粒度相比，这种方式可以将失效范围缩小到实际受影响的子集，但依赖图的维护本身增加了复杂度。对于编译延迟敏感的生产环境，建议先从函数级粒度入手，仅在性能分析显示全局失效成本过高时再考虑依赖图方案。
缓存分层是另一种优化思路。将 IR 缓存与生成的机器码缓存分离存储，前者位于稳定的内存区域或磁盘上，后者在需要时从 IR 缓存重新编译生成。当 IR 缓存失效时，机器码缓存整体失效但可以在后续请求驱动下逐步重建。这种分层设计降低了缓存失效时的瞬时开销，避免因同时清理大量机器码页面导致的内存抖动。
ORC JIT 中的缓存管理实践
LLVM 的 ORC（Optimizing Run-time Compiler）框架为缓存失效提供了结构化的支持。ORC 的核心抽象包括 JITDylib（表示一个符号定义的集合）与 ThreadSafeModule（线程安全的模块封装）。在 ORCv2 架构中，每个 JITDylib 可以独立管理其符号解析与依赖关系，当模块被添加到 JITDylib 时，ORC 自动计算模块哈希并与已有条目比较，若哈希匹配则复用先前解析的符号，否则执行增量重编译。
实践中的最佳做法是为每个逻辑编译单元创建独立的 JITDylib。例如，一个处理用户脚本的运行时可以为每个脚本模块创建专属的 JITDylib，当用户重新加载脚本时，只需替换对应 JITDylib 中的模块即可实现失效，而不影响其他脚本的缓存。这种设计天然支持细粒度的独立失效与资源回收。
ORC 还支持惰性编译（lazy compilation）与立即编译（eager compilation）两种模式。在惰性编译下，符号解析延迟到实际调用时才触发，此时可以基于调用时的运行时条件（如实际使用的 CPU 特性）决定编译策略。如果运行时条件在两次调用间发生变化，ORC 会自动处理符号的重新解析与重编译，无需显式管理失效逻辑。
可配置的工程参数
在生产环境中部署缓存失效策略时，以下参数可作为调优起点：
缓存键哈希算法建议使用 SHA-256；若对计算耗时更敏感，可采用 xxHash64 等非加密哈希，其碰撞概率在缓存键场景下完全可以接受。哈希计算应当缓存中间结果，避免在每次编译请求时重复计算相同的模块内容。
版本号字段宽度取决于缓存条目的预期生命周期。对于长时间运行的服务器进程，64 位无符号整数足以支撑数十年不溢出。若需要持久化缓存到磁盘，版本号还应考虑磁盘存储的序列化格式兼容性。
缓存条目上限通常设置为 1024 至 4096 个函数级条目，或根据可用内存按比例分配 —— 每个条目平均占用数十 KB 的机器码与元数据，总内存预算建议控制在 256 MB 以内。超过上限时采用 LRU（最近最少使用）淘汰策略，优先保留活跃调用的函数。
失效传播的超时阈值建议设置为 50 至 100 毫秒。若依赖图遍历超过该阈值，直接触发全局失效以避免阻塞编译线程。这个参数需要在实际工作负载下通过 Profiling 数据进行调校。
可观测性与监控
缓存失效的效果需要通过指标持续监控。关键指标包括缓存命中率（Hit/Miss Ratio）、失效事件计数（按触发原因分类）、失效后重编译的延迟增量，以及缓存内存占用趋势。建议为每次失效事件附加原因码 ——target_change、ir_mutation、pass_pipeline_change、external_deps_change—— 便于事后分析性能回退的根因。
日志系统应记录哈希值或版本号的变更历史。当发现某次请求的响应时间异常增加时，可以通过日志关联到对应的缓存失效事件，判断是正常的业务逻辑触发失效还是异常的缓存抖动。异常抖动通常意味着哈希计算遗漏了某些影响编译的隐藏状态，需要迭代完善缓存键的组成要素。
资料来源
本文技术细节参考 LLVM 官方文档中关于 ORC JIT 架构的描述，以及 LLVM LangRef 中关于 IR 语义与数据布局的规范。哈希失效与版本化缓存的最佳实践来自 LLVM 社区在 JIT 缓存实现方面的工程经验总结。
来源：LLVM 官方文档（llvm.org）、ORCv2 设计与实现规范（llvm.org/docs/ORCv2.html）