optimize builtins finalizationregistry · Pull Request !12499 · OpenHarmony/arkcompiler_ets_runtime

1. optimize builtins finalizationregistry
---
### 关联的Issue
https://gitee.com/openharmony/arkcompiler_ets_runtime/issues/ICIHRI

### 修改原因（目的、解决的问题等，例如：修复xx场景崩溃问题）
optimize builtin finalizationregistry

### 修改描述（做了什么，变更了什么，例如：xx函数入口增加判空）
When GC callbacks are registered through FinalizationRegistry, the current implementation stores each registered cell in a weakvector.
With a large number of registrations, the vector is repeatedly reallocated and copied, introducing significant performance overhead.
Replacing the vector with a linked list to manage the registered cells optimizes the registration routine.

### 自测试项（测试结果截图，直接贴到每一个测试项底下）
**Performance Testing**
```js
{
    const N = 1000;
    const start = Date.now();

for (let i = 0; i < N; i++) {
        const registry = new FinalizationRegistry(_ => {});
        for (let j = 0; j < 100; j++) {
            const obj = { j };
            registry.register(obj, j);
        }
    }
    const end = Date.now();
    print("register few targets" , end - start, "ms");
}

{
    const N = 100000;
    const start = Date.now();
    const registry = new FinalizationRegistry(_ => {});

for (let i = 0; i < N; i++) {
        const obj = { i };
        registry.register(obj, i);
    }
    const end = Date.now();
    print("register many targets" , end - start, "ms");
}

{
    const N = 100;
    const start = Date.now();
    const registry = new FinalizationRegistry(_ => {});

for (let i = 0; i < N; i++) {
        let token = { i };
        for (let j = 0; j < 10000; j++) {
            const obj = { i };
            registry.register(obj, i, token);
        }
    }
    const end = Date.now();
    print("register many targets with tokens" , end - start, "ms");
}

print()
```
![输入图片说明](https://foruda.gitee.com/images/1751105294678787477/9eeb55d8_5357980.jpeg "8eda8a7e-9d96-4695-b701-e7927ee63161.jpg")

#### jit-workload 本地执行（compiler/jit/isa/stub/ic/对象布局等修改必须执行）
- [ ] 已通过
- [ ] 不涉及，无需验证
#### interpreter-js_perf 性能测试（性能优化/性能敏感场景：IR化/ic/hclass/对象布局/isa/builtins等修改必须执行）
- [ ] 已验证不劣化
- [ ] 不涉及，无需验证
#### aot-js_perf 性能测试（性能优化/性能敏感场景：IR化/ic/hclass/对象布局/isa/builtins等修改必须执行）
- [ ] 已验证不劣化
- [ ] 不涉及，无需验证
#### interpreter-workload性能测试（性能优化/性能敏感场景：IR化/ic/hclass/对象布局/isa/builtins等修改必须执行）
- [ ] 已验证不劣化
- [ ] 不涉及，无需验证
#### aot-workload性能测试（性能优化/性能敏感场景：IR化/compiler/aot/isa/stub/ic/对象布局等修改必须执行）
- [ ] 已验证不劣化
- [ ] 不涉及，无需验证
#### 非StableArray不能采用ElementKind读取元素（修改解释器相关IR代码需要自检）
- [ ] 已自检
- [ ] 不涉及，无需验证
#### 在IR时添加fastpath时，需要检查是否有分支会改变非字典序模式或者修改数组长度，此时应该走slowpath（修改解释器相关IR代码需要自检）
- [ ] 已自检
- [ ] 不涉及，无需验证
#### IR化后的逻辑需要与c++实现一致，不一致的地方需要有分支用例看护（修改解释器相关IR代码需要自检）
- [ ] 已自检
- [ ] 不涉及，无需验证
#### c++代码中检测或抛出异常的地方，IR需要同样实现（修改解释器相关IR代码需要自检）
- [ ] 已自检
- [ ] 不涉及，无需验证
#### IR中使用默认入参是HeapObject对象的接口时，需要在上下文中保证了参数的正确性（修改解释器相关IR代码需要自检）
- [ ] 已自检
- [ ] 不涉及，无需验证
#### 修改c解释器，需要同时检查汇编解释器与AOT是否需要修改
- [ ] 已自检
- [ ] 不涉及，无需验证
### 是否已执行L0用例
- [ ] 已验证
- [ ] 不涉及。如不涉及，请写明理由

类型	指派人员	状态
审查	@klooer 由 CODEOWNERS 文件第 14 行指派为审查者	进行中 (0/1人)
审查	weng-changcheng gonggong 孙哲 Gargoyle.h chuning1988	进行中 (0/1人)
测试	openharmony_ci	进行中 (0/1人)

OpenHarmony/arkcompiler_ets_runtime关闭 .gitee-modal { width: 500px !important; }

搜索帮助

OpenHarmony/arkcompiler_ets_runtime
关闭