RISC-V SHA-3 寄存器常驻与 Parallel Full GC 交错分片

本期检索说明

先读取 content/collections/deep-radar 截至 2026-09-20 的全部原文链接，并按 URL、标题和实现机制去重。最近 24 小时内有两项 OpenJDK 一手改动同时给出源码差异、可量化实测与可解释机制，因此本期收录 2 篇。两篇都仍处于评审早期，结论应理解为“补丁作者在所述环境中的结果”，不是已经进入主线后的跨平台定论。

Rust 的 rustc_builtin_macros 清理声称有性能收益，但官方 rustc-perf 截稿时仍在排队；Tokio 的零容量 BufReader 修复只有正确性测试；Kotlin 当日候选集中在 Valhalla 测试开关和文档；Zig、Linux 最近 7 天内没有找到同时满足实测、源码证据与原理剖析三项标准且未被历史报告收录的材料。第二篇 GC 改动只有一个约 2% 的受益样本、其余 micro benchmark 中性，证据强度低于第一篇，正文会明确保留这一限制。

01 · JVM：让 Keccak-f 的 25 个 lane 常驻 RISC-V GPR

原文与日期： zny666，2026-09-20 21:24（中原标准时间）；OpenJDK PR #32971 与 完整源码 patch。补丁修改 3 个文件，增加 458 行、删除 6 行；截稿时尚未绑定 JBS issue，也未取得所需的两名 reviewer 批准。

为什么值得读： 这不是把一段 Java 循环机械翻译成汇编，而是一份很具体的寄存器压力工程案例。Keccak-f[1600] 有 25 个 64 位 state lane，Theta、Rho、Pi、Chi、Iota 每轮还需要临时值；C2 在 RV64 的有限整数寄存器中无法同时保住这些 live value，于是生成代码频繁 spill/reload。补丁通过固定寄存器布局、两枚通用临时寄存器和少量有意设计的栈槽，把“由分配器被动溢出”改成“由算法调度主动控制”。

核心技术结论： 新 stub 把 lane 0–24 固定映射到 x9–x31、ra 与 fp，将 x10、x12 作为主要临时寄存器；callee-saved 寄存器在 prologue/epilogue 成组保存恢复。Rho 直接使用 Zbb 的 rori，Chi 的 a[i] ^= ~a[i+1] & a[i+2] 直接落为 andn 加 xor。多 block 路径让 state 跨输入 block 保持在 GPR 中，避免每个 block 都把 200 字节状态往返内存。

// 25 个 lane 固定占住寄存器，只有两个通用临时值
Register lane0 = x9,  lane1 = x18, lane2 = x19;
// ...
Register lane23 = ra, lane24 = fp;
Register tmp0 = x12, tmp1 = x10;

// Chi：~lane1 & lane2，由 Zbb andn 一条完成
__ andn(tmp0, lane2, lane1);
__ xorr(lane0, lane0, tmp0);

由于 lane18 与 state base 都会借用 x11，载入顺序也成为正确性的一部分：先载入其余 24 个 lane，最后再覆盖 x11。Theta 阶段只明确 spill lane4、lane9 和一个 Chi 临时值，而不是让编译器在整轮里反复选择牺牲者。能力探测则要求 UseSHA && UseZbb，满足时默认开启 UseSHA3Intrinsics；没有 Zbb 的 RV64 继续走 Java fallback。

最有价值的实验、源码与 benchmark 细节： 作者在一台具备 Zbb 的物理 RV64 机器上，用 release build 比较 -XX:+UseSHA3Intrinsics 与 -XX:-UseSHA3Intrinsics，每个结果取两次独立运行平均值。每次 Keccak-f[1600] 的动态指令约从 7,300–7,600 降到 3,553，减少约 51%–53%；内存指令从约 3,800 降到 302，减少约 92.1%。

吞吐只提升 20%–30%，明显小于动态指令和内存指令降幅，说明瓶颈没有按指令条数线性缩放；可能还受依赖链、执行端口和 load latency 之外的成本约束。测试覆盖 SHA3-224/256/384/512、SHAKE128/256、block 边界、多 block，以及 1–4 路 doubleKeccak 状态比对，intrinsic 与 fallback 结果一致。最大限制是作者未披露具体平台和微架构，而且每点只平均两次，跨实现结论仍需在可公开硬件上复现。

适合的工程师背景： 熟悉 HotSpot StubGenerator、C2 生成代码、RISC-V Zbb 或密码散列实现，希望理解如何把寄存器分配问题转化为显式状态调度的 JVM/编译器工程师。

预计阅读收益： 约 70–100 分钟；能建立 Keccak 五步轮函数、ABI 保存约束、固定 lane 映射和动态指令计数之间的完整因果链，并学会区分“指令减少”与“吞吐同比例增长”。

02 · JVM GC：用交错 region 分片打散 Parallel Full GC 的活对象聚集

原文与日期： Albert Mingkun Yang，2026-09-20 18:02（中原标准时间）；OpenJDK PR #32970、JDK-8392741 与 单文件源码 patch。补丁只改 psParallelCompact.cpp，增加 6 行、删除 25 行；截稿时仍等待两名 GC reviewer。

为什么值得读： 这是一个“总工作量平均不等于实际负载平均”的典型并行 GC 案例。旧实现把 [dense_prefix_region, top_region) 连续切成 N 段；region 数量相近，但如果 live object 在地址上聚集，拿到活跃连续段的 worker 会执行更多 forwarding，而拿到稀疏段的 worker 提前空闲，Full GC 的并行阶段最终受最慢 worker 限制。

核心技术结论： 新实现让 worker i 从 dense_prefix_region + i 开始，每次跨过 _num_workers 个 region。相邻 region 被轮转到不同 worker，地址局部的活对象团簇因而被摊开。它不改变 region 内 partial_obj_size、destination 计算或对象顺序，只改变 region 到 worker 的静态映射。

// 旧：每个 worker 取得一个连续区间
for (size_t cur = start_region; cur < end_region; ++cur) { ... }

// 新：相邻 region 轮转到不同 worker
size_t start_region = dense_prefix_region + worker_id;
for (size_t cur = start_region; cur < top_region; cur += _num_workers) { ... }

代价也很清楚：每个 worker 的访问步长变大，可能削弱 summary data 与 region metadata 的空间局部性。不过这段阶段的主要不均衡来自 live-object 分布；补丁选择用更均匀的工作量换取可能更差的元数据 cache locality。

最有价值的实验、源码与 benchmark 细节： 作者运行 SystemGC micro benchmark，报告“大多数中性”，专门构造前半段死亡、后半段存活分布的 HalfDeadFirstPart.gc 改善约 2%。这个结果与机制相符：它只有在连续分片恰好把活跃 region 集中给少数 worker 时受益；均匀 live 分布原本已经平衡，所以不应期待普遍提升。

证据仍有三个边界：PR 没公布绝对 pause time、worker phase 分布或误差；只点名一个约 2% 的受益样本；也未给 NUMA 和不同 worker 数量结果。因此可迁移的结论是“先检查空间聚集是否造成静态连续分片失衡”，而不是“交错分片一定更快”。生产复核应同时比较 Full GC pause、各 worker forward_to_new_addr 时间离散度、LLC miss 与跨 NUMA 流量。

适合的工程师背景： 熟悉 Parallel GC compacting、region summary table 或其他静态并行分片算法，正在排查 phase 尾部 worker imbalance 的 JVM 与运行时工程师。

预计阅读收益： 约 30–45 分钟；可以快速掌握连续块分片与 cyclic distribution 的工程权衡，并得到一套用 worker phase 数据而非总吞吐判断负载均衡的复测思路。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-08-23 至 2026-09-21，单位人民币，六类硬件固定同一 SKU。今天直接复核到 CPU、GPU、主板、HDD、SSD 五个页面的当前最低报价；DRAM 页面明确显示“暂无报价”，所以不新增价格点。重复价格仍作为真实采样保留，用于区分“已复核横盘”和“没有证据”；SSD 页面同时显示 2TB 规格与 ¥749 起价，但天猫、京东价差仍很大，继续按渠道风险事件处理。

价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。

判断依据

CPU 当前价只比 9 月 19 日低 ¥10，尚不足以确认新一轮下跌；若不急，等待重新接近 ¥2,449 的窗口低点更合理。GPU、主板与 HDD 今天的重复点提供了“当前仍可见”的证据，其中主板较窗口首点已低 ¥150。DRAM 缺价，不能拿其他时序或容量替换。SSD 的 ¥749 与同页京东 ¥1,889 差距过大，即使页面规格栏显示 2TB，也应在结算页再次核对规格与保修。

其它你可能关心的

• rustc_builtin_macros cleanup, part 5——源码重构与潜在性能收益有价值，但官方 rustc-perf 截稿时尚未完成，不提前引用结果。
• Tokio：零容量 BufReader 不再把 buffered API 误报为 EOF——机制与回归测试完整，但没有性能实测。
• OpenJDK：RISC-V interpreter/C1 Float16 conversion intrinsic——源码层次丰富，但作者明确尚未在目标硬件运行测试。

本期结论

SHA-3 intrinsic 展示了固定寄存器布局的真正价值：不是“汇编天然更快”，而是把 25 个长生命周期 lane、ABI 保存和少量必要 spill 一次性编排清楚，最终动态指令减半、内存指令减少九成，吞吐提升 20%–30%。Parallel Full GC 的交错分片则提供了一个更小但可迁移的教训：当工作量沿地址空间聚集时，等长连续区间并不等价于等负载；不过单一 2% 样本仍需 worker phase 与缓存指标复测。硬件五类拿到当日真实采样，DRAM 缺价继续留白。