本期检索说明
先读取 content/collections/deep-radar 截至 2026-10-14 的全部原文链接，并按 URL、标题与实现机制去重。最近 24 小时内，OpenJDK AArch64 SVE 窄化存储同时具备 JMH、机器描述源码与原理证据；再按规则回溯最近 7 天，收录 Linux 页缓存小读的 RCU 延迟释放补丁组。本期 2 篇均未在既往报告中出现，且分别覆盖 JVM 与 Linux，避免继续增加近期已较密集的 Rust 选题。
Kotlin/Wasm 协程性能修复给出了源码与根因方向，但没有可复核的定量 benchmark；近期 Zig 候选没有同时满足实测、源码和原理三项标准。Rust Span niche 与 query-cache 去重候选虽有 rustc-perf，当前 primary instruction 样本仍出现回退，且工程结论尚未收敛，因此不凑数。两项入选工作截稿时都仍在开放评审：Linux 补丁的 22.9 倍来自 64 线程争抢同一缓存页的合成上限场景，并已有评审者指出文件扩展竞态；OpenJDK PR 仍是 Draft，数据只覆盖 Graviton4 的 128-bit SVE。以下结论保留这些边界，不把开放补丁写成已发布特性。
| 主题 | 原始发布日期 | 一手来源与交叉验证 | 截稿状态 | 推荐强度 |
|---|---|---|---|---|
| AArch64 SVE store-time narrowing | 2026-10-15 07:53（中原标准时间） | OpenJDK PR #33373 / JBS JDK-8392998 / 完整机器描述 diff / JMH | Draft | 推荐，重点看 xtn + str 怎样折叠成 st1b/st1h |
| RCU 延迟释放页缓存 folio | 2026-10-14 05:26（中原标准时间） | LKML v3 补丁组 / Linux 源码分支 / LWN 技术审阅 / perf 数据 | 开放评审 | 强烈推荐，重点看 refcount cacheline 争用怎样被生命周期协议替代 |
01 · OpenJDK：让 SVE 在写回内存时直接完成窄化
原文与日期： Boris Ulasevich，2026-10-15 07:53（中原标准时间）；OpenJDK PR #33373、完整源码 diff 与 JBS JDK-8392998。
为什么值得读： C2 已能把 int[] 到 byte[]/char[] 的逐元素转换向量化，但 AArch64 SVE 旧代码生成会先用 xtn 把 vector register 窄化，再用普通 str 写回。SVE 的 st1b 与 st1h 本身就能从 32-bit lane 取低 8/16 位存储，独立窄化指令、临时结果和对应依赖链都是多余工作。这个改动很适合迁移到 SIMD 后端优化：不要只在算术 IR 中找冗余，也要检查 load/store 是否已经融合类型转换语义。
核心技术结论： 补丁在 AArch64 C2 .ad 机器描述中新增 storeV_narrow_ItoB 与 storeV_narrow_ItoS，匹配 StoreVector(VectorCastI2X(src))；当 UseSVE > 0 且 vector 宽度等于 MaxVectorSize 时，直接调用 loadStoreA_predicated()，以源元素 T_INT、内存元素 T_BYTE/T_SHORT 选择窄化 store。它还新增与目标内存元素缩放一致的 4-bit signed-offset operand，避免把 int lane 宽度错误套到 byte/short store 地址编码上，并用 IR framework 节点检查确保规则实际命中。
旧路径：int lanes ── xtn ──> byte/short lanes ── str ──> memory
新路径：int lanes ─────────────── st1b/st1h ──> memory最有价值的实验、源码与 benchmark 细节： 作者在 Graviton4、SVE 128-bit、数组长度 1,024、JMH avgt 9 次采样下给出：
| Benchmark | 修改前 | 修改后 | 延迟变化 | 加速比 |
|---|---|---|---|---|
VectorSubword.intToByte |
78.043 ± 0.701 ns/op | 65.432 ± 0.088 ns/op | -16.16% | 1.193× |
VectorSubword.intToChar |
72.976 ± 0.296 ns/op | 66.978 ± 0.442 ns/op | -8.22% | 1.090× |
源码证据不只是新增两条选择规则：IRNode 同步加入 AARCH64_STORE_V_NARROW_I2B/I2S，TestVectorizeTypeConversion 在检测到 SVE 时要求窄化 store 节点出现，从而把“生成了目标指令形态”纳入回归测试。限制也很清楚：结果来自单台 Graviton4、固定 128-bit SVE 与 1,024 元素热循环；PR 尚未完成两位 reviewer 要求，不能外推到所有 SVE 宽度、数组长度或已发布 JDK。
适合的工程师背景： 熟悉 HotSpot C2 SuperWord/Vector API、AArch64 SVE 或正在维护 LLVM/GCC 类指令选择器的编译器工程师。
预计阅读收益： 约 30–45 分钟；能掌握如何从 ISA 的 narrowing-store 语义反推 matcher 规则、地址 operand 与 IR regression test，并用 JMH 验证少一条向量指令是否真正缩短关键路径。
02 · Linux：用 RCU 延迟复用消除页缓存小读的 folio refcount 热点
原文与日期： Linus Torvalds，2026-10-14 05:26（中原标准时间）；LKML v3 补丁组、补丁源码与完整实验记录 与 LWN 技术审阅。
为什么值得读： 多线程反复 pread() 同一个已缓存小文件时，数据本身只读，传统 filemap 路径却必须为 folio 获取和释放引用。filemap_get_read_batch() 的 locked compare-exchange 与 filemap_read() 的 atomic decrement 会让所有 CPU 写同一个 struct page cacheline；随着核心数增加，瓶颈从内存拷贝转成 cacheline ownership 往返。补丁没有尝试把 refcount 原子操作“做快一点”，而是改变对象复用协议：读者不再持有引用，页离开 page cache 后必须等 RCU grace period 才能重新分配。
核心技术结论： 热 folio 被标记为 PG_rcu_free；无引用读取路径在 rcu_read_lock() 内关闭用户页 fault，确认 folio 仍匹配 xarray 与文件偏移后直接 copy_page_to_iter()。folio 从 page cache 移除时先进入 per-CPU pending/batch 队列，等 grace period 后才真正归还 allocator；待回收页超过阈值时主动加速 RCU，分配器也在内存紧张时考虑这些“已释放但尚不可复用”的页。只有被识别为热读的 folio 承担延迟释放，避免把全部 page-cache eviction 都拖入 RCU 队列。
最有价值的实验、源码与 benchmark 细节： 64 线程 Ryzen Threadripper 在同一缓存页执行小读：
| 指标 | 基线 | RCU 无引用读取 | 变化 |
|---|---|---|---|
| 吞吐 | 13.3M reads/s | 304M reads/s | 22.86× |
| cycles/read | 19,857–19,939 | 735–736 | 约 -96.3% |
| instructions/read | 1,094–1,101 | 959 | 约 -12.5% |
较早的 8 线程、16-byte pread() 样本也从约 9.9–10.4M 提升到 30–33M reads/s；perf c2c 的 load HITM 从 30,538 降到 101，直接支持“共享 refcount cacheline 是主因”，而不只是 wall-clock 巧合。正确性压力测试在约 10^8 次 eviction-race 读取与 115 万次 partial-fault 读取中没有发现坏数据；用于验证测试灵敏度的“立即复用”对照分别捕获 12 和 138 次坏读。
代价同样重要。16-byte 读取遇到缺失用户页时，cycles 从约 4,117–4,188 上升到 6,543–6,593，约回退 58%；1 MiB 大读的 instruction count 增加约 6%。早期只做延迟释放时，等待 grace period 的内存可达 565 MiB、峰值约 1.0–1.2 GiB；加入批处理与主动推进后，4 CPU 样本降至 15 MiB，避免了早期版本在 4/8 CPU VM 上的 OOM。LWN 评审还指出 filemap_read_rcu_batch() 在 folio 被替换且 i_size 扩展时可能暴露未写入数据的竞态；补丁仍在演进，22.86× 是极端共享页上限，不是普通文件服务器的收益预测。
适合的工程师背景： 熟悉 Linux page cache、folio/xarray、RCU 与 perf c2c，或正在处理只读热对象 refcount 扩展性问题的内核/运行时工程师。
预计阅读收益： 约 60–80 分钟；能学会用 HITM 将吞吐塌陷定位到 cacheline ownership，并理解“省掉读侧引用”必须同时重构对象回收、内存压力反馈、page fault 与竞态验证。
中国大陆 ToC 硬件价格观察
数据口径
窗口为 2026-09-16 至 2026-10-15，单位人民币，六类硬件固定同一 SKU。今天通过公开比价页的实时渲染结果复核到 CPU、GPU、主板、HDD、SSD 五类报价；DRAM 页面仍显示“暂无报价”，因此不新增点。重复价格作为真实采样保留，用来区分“已复核横盘”和“未取得数据”。SSD 只记录固定 2TB 规格的全网比价，不采用页面跨容量的 819 元起；主板只记录当前规格全网比价，不采用系列页的 1,169 元起。
| 类别 | 10 月 15 日可复核价 | 30 日窗口内真实走势 | 建议 |
|---|---|---|---|
| CPU | Ryzen 7 9800X3D，京东 ¥2,609 | 9/17 ¥2,619 → 9/23 ¥2,579 → 10/1–8 ¥2,694–2,699 → 10/9–15 ¥2,609 | 可关注但不追价；已连续七日横盘，仍比窗口低点高 ¥30 |
| GPU | MSI RTX 5070 VENTUS 3X 12G，亚马逊中国 ¥4,464.34 | 9/16–10/15 多次实时复核均为 ¥4,464.34 | 刚需可比价后入手；单一渠道横盘不等于全市场无促销 |
| 主板 | ASUS TUF B850M-PLUS WIFI7，天猫当前规格 ¥1,298 | 10/12–14 记录的 ¥1,169 来自系列起价；10/15 当前规格全网比价为 ¥1,298 | 观望并核对规格；图上 +11.0% 主要是报价口径校正，不能当作一天市场涨幅 |
| DRAM | 暂无报价；最后可复核 9/9 ¥3,900 | 本窗口没有可比报价 | 观望；固定 SKU 缺价，不用其他容量、颗粒或时序替代 |
| HDD | IronWolf Pro 8TB ST8000NE001，i百联 ¥1,849 | 9/16–10/15 多次复核均为 ¥1,849 | 容量刚需可买；先核对型号、五年保修与数据恢复服务 |
| SSD | ZHITAI Ti600 2TB，京东 ¥1,699 | 9/23–10/11 ¥1,799 → 10/12–13 ¥1,739 → 10/14 ¥1,799 → 10/15 ¥1,699 | 可入手或继续比价；创窗口新低，单日下降 ¥100（5.56%），但仍是单一渠道事件 |
价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。
判断依据
CPU、GPU 与 HDD 今日继续横盘。9800X3D 已从国庆期间 ¥2,699 档回落，但仍未触及 9 月 23 日 ¥2,579；GPU 与 HDD 在窗口内缺少方向性变化。Ti600 2TB 当前规格从昨日 ¥1,799 降至 ¥1,699，创本窗口新低，刚需可将其作为比价锚点，但一天的单渠道降价不足以证明 NAND 原厂价格趋势。主板页面今天同时显示产品系列 1,169 元起 与当前规格全网比价 1,298 元，后者才与固定 B850M-PLUS WIFI7 SKU 对齐；因此数据改用 ¥1,298，并把图中跳变解释为统计口径修正。DRAM 固定 SKU 继续缺价，走势图保留真实空白尾段。本期没有加入未经核实的新品或产能消息。
其它你可能关心的
本期结论
两项工作都把“中间状态”折叠进更强的底层语义：SVE store 直接承担 lane 窄化，RCU grace period 直接承担无引用读取后的生命周期安全。前者是局部指令融合，后者是跨 allocator、page cache 与 fault handling 的协议重构；共同的工程方法是先用源码与硬件计数器证明中间步骤确实是瓶颈，再把正确性条件写进 matcher、回收队列和回归测试。性能数字必须连同适用边界阅读：一个只覆盖单款 SVE 机器，另一个刻意构造最严重的共享 cacheline 争用。