QuickJS-NG引擎中的FinalizationRegistry内存管理问题分析

QuickJS-NG作为一款轻量级JavaScript引擎，其内存管理机制一直是开发者关注的重点。近期发现的一个涉及FinalizationRegistry的段错误问题，揭示了引擎在垃圾回收过程中对弱引用处理的潜在缺陷。

问题现象

当执行包含FinalizationRegistry的特定测试用例时，引擎会触发段错误(SIGSEGV)。测试代码创建了一个自引用的FinalizationRegistry实例，并注册了一个包含ArrayBuffer的清理回调。错误发生在垃圾回收阶段，具体是在find_own_property_ic函数尝试访问已释放内存时。

技术分析

问题根源在于FinalizationRegistry的生命周期管理。当引擎执行垃圾回收时，会触发以下关键流程：

1. 垃圾收集器开始释放不再使用的对象
2. 遇到FinalizationRegistry实例时，尝试执行注册的回调函数
3. 回调函数执行过程中需要访问全局变量
4. 此时相关内存可能已被释放，导致空指针访问

特别值得注意的是，这个问题出现在自引用场景下，即FinalizationRegistry的回调函数指向自身。这种循环引用情况使得内存管理更加复杂。

解决方案

开发者通过将回调处理移至作业队列(job queue)中执行，有效解决了这个问题。这种改进带来了两个关键优势：

1. 执行时机控制：将回调执行与垃圾回收过程解耦，确保在安全的环境下处理弱引用
2. 内存安全：避免了在垃圾回收过程中直接访问可能已被释放的对象

技术启示

这个案例为我们提供了几个重要的JavaScript引擎开发经验：

1. 循环引用处理：引擎需要特别处理自引用和循环引用场景
2. 垃圾回收时序：回调执行时机对内存安全至关重要
3. 弱引用管理：FinalizationRegistry等弱引用机制需要与主垃圾回收流程协调工作

QuickJS-NG通过这个修复，进一步提升了其在复杂内存管理场景下的稳定性，为开发者提供了更可靠的运行环境。这个案例也提醒我们，在使用弱引用特性时需要特别注意其生命周期管理。