LuaJIT 中字符串连接元方法记录时的内存管理问题分析

问题背景

在 LuaJIT 的即时编译(JIT)过程中，当记录(recording)字符串连接操作(__concat 元方法)时，如果遇到内存不足(OOM)的情况，虚拟机状态无法正确恢复，导致断言失败和程序崩溃。这个问题与之前修复的 #1234 号问题类似，但此次发生在字符串分配的折叠优化阶段。

技术细节

问题重现

通过一个精心设计的测试用例可以重现此问题：

1. 创建一个包含 __concat 元方法的表
2. 在 JIT 编译的热循环中进行字符串连接操作
3. 通过自定义内存分配器在特定条件下模拟 OOM 情况

当 JIT 尝试记录字符串连接操作时，如果分配大字符串失败，虚拟机状态无法正确回滚，导致后续断言失败。

问题根源

问题出现在 lj_record.c 文件的字符串连接记录逻辑中。当执行以下操作时：

1. 记录字符串连接操作
2. 调用 __concat 元方法
3. 在结果字符串分配过程中发生 OOM

此时，虚拟机没有通过受保护的调用(cpcall)机制来确保状态可恢复，而是直接进行了可能失败的内存分配操作。

影响范围

此问题影响：

• 所有使用 __concat 元方法的场景
• 在 JIT 编译过程中进行字符串连接操作
• 系统内存紧张或人为限制内存分配的情况

解决方案

修复方案是采用与 #1234 问题相同的处理方式，将相关操作放入受保护的调用环境中。具体来说：

1. 将字符串连接的折叠优化操作放入 cpcall 保护中
2. 确保在内存分配失败时能够正确回滚虚拟机状态
3. 保持原有的优化逻辑不变，仅在错误处理上增强

技术意义

这个修复体现了 LuaJIT 在以下方面的设计考量：

1. 错误恢复的鲁棒性：确保在资源不足时能够优雅降级
2. JIT 编译的安全性：保护编译过程不受运行时条件影响
3. 一致性：保持与之前类似问题的处理方式一致

开发者建议

对于 LuaJIT 开发者和使用者，建议：

1. 在实现元方法时考虑资源限制的情况
2. 对于可能引发内存分配的操作，使用保护机制
3. 在性能关键路径上，预先分配必要资源

这个修复确保了 LuaJIT 在极端条件下的稳定性，维护了其作为高性能 Lua 实现的可靠性。