QuickJS-NG 中的 FinalizationRegistry 回调同步执行问题分析

问题背景

在 JavaScript 引擎 QuickJS-NG 中，FinalizationRegistry 是一个用于管理对象垃圾回收回调的 API。根据 ECMAScript 规范，FinalizationRegistry 的回调应当异步执行，但在 QuickJS-NG 的当前实现中，这些回调会被同步触发，这可能导致严重的运行时问题。

问题现象

当开发者创建一个 FinalizationRegistry 并在其回调中再次创建新的 FinalizationRegistry 实例时，会导致递归调用和堆内存使用后释放(use-after-free)问题。具体表现为：

1. 创建 FinalizationRegistry 并注册临时对象
2. 临时对象被立即回收，触发回调
3. 回调中又创建新的 FinalizationRegistry 并注册新对象
4. 这一过程无限递归，最终导致堆栈溢出或内存访问违规

技术分析

QuickJS-NG 使用引用计数作为其主要垃圾回收机制。当对象引用计数归零时，会立即触发回收操作。对于 FinalizationRegistry 注册的对象，这种即时回收会导致回调被同步执行。

根据 ECMAScript 规范，FinalizationRegistry 的回调应当通过作业队列(Job Queue)异步执行。规范明确指出应使用 HostMakeJobCallback 包装清理回调，确保它们不会同步执行。

解决方案

正确的实现方式应该是：

1. 将 FinalizationRegistry 的回调包装为作业
2. 将作业放入作业队列而非立即执行
3. 在适当的事件循环周期中执行这些回调

这种异步执行机制可以避免递归调用和内存安全问题，同时也符合 ECMAScript 规范的要求。

实现影响

这一修改将带来以下影响：

1. 行为更符合标准：与主流 JavaScript 引擎(V8、SpiderMonkey 等)保持一致
2. 提高稳定性：避免递归调用导致的堆栈溢出
3. 防止内存安全问题：消除 use-after-free 风险
4. 性能影响：回调执行会有轻微延迟，但这是符合预期的行为

开发者建议

对于 QuickJS-NG 的使用者，应当注意：

1. 不要依赖 FinalizationRegistry 回调的同步执行特性
2. 在回调中避免执行可能触发新垃圾回收的操作
3. 理解 FinalizationRegistry 主要用于资源清理而非业务逻辑

这一问题的修复将使 QuickJS-NG 在垃圾回收相关 API 的实现上更加健壮和符合标准。