docs(vm): discuss execution architecture redesign - #21
Conversation
a701862 to
7788c22
Compare
Save the compiler and publication refactors, instruction contracts, profiling, and owned frame/slot execution with the in-progress S04 call, binding, conversion, and unwind migration. Validation: driver 76, run 9, and eval 142 tests pass; formatting, source layout, and boundary scan pass. Three native-stack tests remain failing. S04 is not accepted and S05-S10 remain pending; this is an implementation checkpoint.
Return root handoffs through the bytecode entry before invoking the legacy driver, and separate ordinary call dispatch from larger cold temporaries. Track real module host delimiters and verify captured bindings, readonly imports, unwind cleanup, and finite versus infinite recursion. Add scoped call preparation diagnostics and share unary-plus primitive semantics to preserve BigInt errors and callback numeric representations. Update migration evidence and boundary canaries with the implementation.
S04 实测回归:benchmark、硬件计数与 Profile 证据测量日期:2026-09-13。源码固定为 结论:启用 S04 这是同提交旧 VM(默认配置)与 1. 测量方法与可复现身份
# 在上述提交的干净工作区,两个命令分别执行、输出目录保持独立
cargo build --locked --release -p quickjs-oxide-cli --no-default-features --jobs 2 --target-dir target/s04-benchmark/legacy
cargo build --locked --release -p quickjs-oxide-cli --no-default-features --features stack-vm --jobs 2 --target-dir target/s04-benchmark/stack
python3 scripts/benchmark/fixed.py --manifest docs/reports/data-structure-fixed-final.json --engine legacy=target/s04-benchmark/legacy/release/qjs --engine stack=target/s04-benchmark/stack/release/qjs --repeat 5 --cpu 2 --timeout 60 --output target/s04-benchmark/fixed-58构建时两者均设置 2. Benchmark 完整结果50 项 microbench 全部可比较。几何平均 展开完整 58 项结果(ms;正数表示新配置更慢)
**执行能力回归:**固定版 3. 硬件指令证据:额外执行工作已确认在同一批二进制上另行运行 这是用户态机器指令/CPU cycles,不是 JS 字节码数,也不是 wall time。它证明回退伴随实际执行工作增加;不提供各原因的独立耗时占比。
展开所有硬件计数中位数
4. Profile:真实运行的热点另外使用
空循环中 普通调用旧配置也有 5. 源码与实际 release 汇编相互印证A. 栈检查的粒度与热循环不匹配,重复调用实际保留。
这不只是源码形式。原 benchmark release 二进制中真实存在: 4c8a47: call SlotStore::peek ; pop 再次调用 peek
4c8b38: cmp (%rdx),%rax ; owner 身份检查
4c8bba: cmp 0x8(%rdx),%rax ; window ID 检查
4c8bc8: cmp 0x18(%rdx),%rax ; arena 末端检查
4c8bdb: sub %rcx,%rdi ; 栈深计算/随后检查
4c8c38: cmp %rax,%rdi ; 槽索引边界检查
B. 原语复制仍进入处理全部 Value 的通用未内联函数。 copy_value 实现 同时处理整数、浮点以及 Object/Symbol 的可失败引用操作。汇编入口保存 5 个寄存器, C. 显式帧迁移没有同时合并构帧存储流程。 BytecodeCallRequest::prepare 先调用共享 汇编 6. 分析、问题归属与后续验收
**纠正尚无证据的归因:**PC 逐指令更新在源码中存在,但本次没有隔离其成本,不能列为已证实的主要回退原因。Earley-Boyer 只确认失败,未确认根因。上述 Profile 百分比不是各原因对总回退的贡献;内联/融合/存储变更能挽回多少,需要保持语义的隔离 A/B 实验。 7. 原始证据保留位置本评论已内嵌完整 benchmark 表、全部硬件计数中位数、热点与关键汇编,便于离开当前会话阅读。原始文件目前保存在 PocketLab 当前工作区的
验证:24 个计数进程、6 次采样输出全部匹配;6 份 Profile lost samples 均为 0;二进制 SHA-256 与测量收据一致。 |
Share prepared property reads across object and primitive receivers, resume object key conversion, and normalize bound callbacks. Own pending synchronous call requests outside the resident dispatcher, expose bridge profiling, and add regression tests and S05 progress documentation.
S05 当前检查点复测:基础回归仍在,属性读取新增开销测量日期:2026-09-13;本次 PR 提交固定为 **阶段状态更正:**开始和复测结束时核对的 PR HEAD 均为上述提交,但该提交的 迁移账本 与 提交计划 明确写着 S05 实施中、尚未验收。因此本评论是最新 S05 检查点结果,不能称为 S05 完成后的最终验收。 **主要结果:**完整 50 项固定 microbench 中,当前新核心相对本轮重新运行的 S04 新核心,等权几何平均耗时变化 +1.05%;相对当前同提交旧 VM 为 +11.95%。约 1% 的跨提交整体差异不宣称统计显著,当前新旧 VM 的明显差距仍在。固定 Earley-Boyer 在 S04/当前两版新核心均 5/5 次栈溢出,当前旧 VM 5/5 次通过。 1. 方法与比较口径
2. 完整 benchmark正数表示当前新核心更慢;50 项几何平均是等权用例汇总,不代表任意应用。小幅单项差异不宣称显著。 展开全部 58 项(ms,5 轮中位数)
关键变化:普通调用相对 S04 wall time -5.21%,闭包调用 -4.39%,TypedArray 读取 -9.16%;属性读取 +6.19%。空循环 +0.62%、整数运算 -0.05%,基础回归没有消失。下节硬件计数用于核对执行工作量的变化,不能只凭 wall time 归因。 **Earley-Boyer:**当前旧 VM 中位数 2672.23 ms;两版新核心全部失败,默认预算未改。当前错误 3. 硬件计数:哪些执行工作确实改变了
全部硬件计数中位数
4. 新一轮 Profile 与机器码
当前 release 实际汇编: 647347: call 647430 <SlotStore::peek> ; pop 内部仍再调用 peekSlotStore::pop/check_current/copy_value 与共享构帧准备相对 S04 源码未改。新二进制中 15 份采样的前 6 个符号(含本轮 S04 对照)array_read-s04_stack.report.txt array_read-s05_legacy.report.txt array_read-s05_stack.report.txt empty_loop-s04_stack.report.txt empty_loop-s05_legacy.report.txt empty_loop-s05_stack.report.txt func_call-s04_stack.report.txt func_call-s05_legacy.report.txt func_call-s05_stack.report.txt prop_read-s04_stack.report.txt prop_read-s05_legacy.report.txt prop_read-s05_stack.report.txt typed_array_read-s04_stack.report.txt typed_array_read-s05_legacy.report.txt typed_array_read-s05_stack.report.txt 5. 更新后的分析:已证实、未证实与修复责任
**继续保留的证据边界:**没有确认 PC 更新的独立成本,没有测量全部分配/retain/release,没有证明任何单一改动能消除全部回退。本轮没有修改生产代码、提高预算、改断言或增加 skip。 6. 复现与证据位置# 当前提交分别构建,关闭 profiling,目录独立
cargo build --locked --release -p quickjs-oxide-cli --no-default-features --jobs 2 --target-dir target/s05-benchmark/legacy
cargo build --locked --release -p quickjs-oxide-cli --no-default-features --features stack-vm --jobs 2 --target-dir target/s05-benchmark/stack
python3 scripts/benchmark/fixed.py --manifest docs/reports/data-structure-fixed-final.json --engine s04_stack=target/s04-benchmark/stack/release/qjs --engine s05_legacy=target/s05-benchmark/legacy/release/qjs --engine s05_stack=target/s05-benchmark/stack/release/qjs --repeat 5 --cpu 2 --timeout 60 --output target/s05-benchmark/fixed-58构建时两套新二进制均设置 本评论内嵌全部 benchmark 和硬件计数中位数、热点及分析。原始数据保存在 PocketLab 本工作区
最终校验:870 个样本完整,失败类型/数量已核对;54 次 perf stat 输出匹配;15 次采样输出匹配且 lost samples 为 0;三套二进制哈希与收据一致。 7. S01–S10 计划、双执行器与回归处理的澄清“性能退化”和“执行路径回落”是两件事:前者指同一工作量变慢/资源成本增加,后者指新核心尚未支持的路径交给旧执行器。路径回落不一定更慢,也不能当作新核心已实现该能力。
当前确实有新旧两套执行核心共存,不是为旧版 JavaScript 保留向后兼容 VM。 Cargo 的 计划考虑了性能风险,但早期防线不足。 它安排了 S01 的诊断、S03/S04 的成本记录、S05 的 Earley-Boyer 覆盖筛查、S08/S09 的隔离 A/B 和无收益实验删除,以及 S10 的完整实测。它并未给每个 S03–S07 检查点建立明确的同源性能退化门槛,因此“门禁通过”和“性能退化仍存在”同时发生。它也没有授权对已知明显退化不作处理;优化阶段不是自动修复承诺。 优化与修复会重叠,应合并到同一问题账本。 例如槽操作重复检查和通用复制热点,既是当前回归,又属于 S08/S09 的优化范围;只需一个修复实现、一次独立 A/B 和对应验收,不应先做临时补丁再在 S08/S09 重写相同工作。性能回归、旧路径覆盖缺口、语言/资源错误分别登记,避免用“迁移完成”或“速度接近”混淆验收。 建议执行顺序:
这比“所有问题一律等 S08/S09”或“为了现在修完而把整个后半段重做一遍”都更可审查。上述内容是基于本轮证据的计划调整建议;本次仅发布分析,没有修改实施计划文件或生产代码。 |
本 PR 当前只保留设计计划与兼容性清单,基于 PR #19。之前的实现已撤回;benchmark 工具、报告、比较数据和已撤回实现的验证记录均已从当前 PR 内容移除。
当前没有引擎代码改动,没有完成优化,也没有可申报的性能收益。
计划仍待根据设计讨论修订,尤其是撤回“首版必须采用 SSA”的决定,重新评估如何保留原有完整编译体系并改进执行架构。现有文档不是已确认的实施方案,PR 尚不具备合并条件。
后续目标仍是同时完成合理、可维护的架构与 issue #16 本轮问题的解决。本文不关闭 #16,也不声称完成 #20 的 Task/Fiber 设计。