Polonius 活跃借用布局与 Shenandoah 队列预平衡

本期检索说明

先读取 content/collections/deep-radar 中截至 2026-08-27 的全部原文链接，并按标题与技术主题复查，未重复收录上一期的 C2 循环变量消除、Generational Shenandoah 标记热循环或更早的 Rust next trait solver。检索窗口优先覆盖 2026-08-27 至 28 日；本期三篇全部来自最近一天，无需用旧文补足数量。

最终收录 2 篇 Rust、1 篇 OpenJDK 一手 PR。Kotlin、Zig 与 Linux 在本窗口内没有同时满足实测、源码证据、原理闭环和工程迁移价值的新增材料，因此不以发布说明或浅层教程凑数。三项补丁截至 2026-08-28 08:54（北京时间）均仍在评审，正文只描述已公开的实验与实现，不把它们写成已进入稳定版的能力。

01 · Polonius：低于 10 bit 的借用维度，不值得配一片 32-byte 小对象森林

原文与日期： panstromek，2026-08-27；rust-lang/rust PR #161850，性能结果见同 PR 中的 rustc-perf comparison。

为什么值得读： 这是一个很典型的数据布局反例：抽象上稀疏，不代表实现上真的省内存。Polonius 的活跃借用矩阵以 MIR PointIndex 为一维、BorrowIndex 为另一维；约 90% 的场景中借用维度不足 10 bit，但旧实现仍为大量程序点分配 32-byte DenseBitSet 外壳，并让每个外壳再指向堆上的 u64。补丁没有改借用规则，只是让物理布局匹配真实维度分布。

核心技术结论： 旧 SparseBitMatrix<PointIndex, BorrowIndex> 只在“某行完全不存在”时节省空间；一旦大多数程序点都有少量活跃借用，行对象、指针和分配器元数据就成为主要成本。新实现用一个 GrowableBitSet<usize> 承载所有位，索引统一计算为 point + num_points * borrow，把多次小分配变成单个可增长 Vec，并使访问路径退化为一次乘加与位测试。

最有价值的实验、源码与 benchmark 细节： 核心改动不是 API 包装，而是明确改变矩阵的物理寻址：

pub(crate) struct LiveLoans {
    num_points: usize,
    flat_matrix: GrowableBitSet<usize>,
}

let bit_index = row.index() + self.num_points * col.index();
self.flat_matrix.insert(bit_index);

rustc-perf 的可靠指标 instructions:u 在 9 个 primary benchmark 上平均改善 0.4%，范围为 0.2%–0.6%，无指令数回退；bootstrap 从 475.228s 降至 473.78s，约改善 0.30%。但 Max RSS 并没有同步变好：出现结果的 primary 样本平均反而增加 3.1%，四个回退样本范围为 2.6%–10.3%。这项负结果很重要：它说明“减少小对象”在局部结构上成立，却不能直接外推为整个 rustc 峰值内存下降；峰值阶段、GrowableBitSet 扩容与测量噪声仍需单独剖析。

适合的工程师背景： 正在研究 Polonius/NLL、编译器数据流分析，或需要为二维稀疏状态选择 bit matrix、flat bitset、Roaring bitmap 等表示的编译器与基础设施工程师。

预计阅读收益： 约 25–35 分钟；能获得一条可迁移的数据结构审计方法：先测每一维的真实基数与占用分布，再判断“稀疏容器”的对象开销是否已经超过有效 bit 本身，并同时检查指令数与峰值内存，避免只验证单一指标。

02 · Miri 精确测试：从复制 2,787 个描述符，降为 O(f log n) 后只克隆命中项

原文与日期： Ralf Jung，2026-08-27；rust-lang/rust PR #161868，问题背景见 Miri issue #5013。

为什么值得读： cargo miri nextest 会为每个测试启动一个 Miri 实例；如果每个实例在真正执行目标测试前都复制整份测试目录，那么一个本应精确命中的操作仍然承担全量成本。这个案例把“已经有二分查找”却仍然慢的原因追到更早一层：二分前，libtest 已经把静态数组中的全部 TestDescAndFn 克隆进 Vec，一半左右的解释器准备时间浪费在永远不会运行的测试上。

核心技术结论： PR 把未过滤测试集改为借用的 TestList<'a>，rustc --test 生成 static TestDescAndFn 和静态引用数组；--exact 且输入已按名称排序时，直接对 &[&TestDescAndFn] 为每个过滤条件做二分查找，只克隆命中项。复杂度从至少一次 O(n) 全量复制，变成 O(f log n + k)：f 是过滤器数量，k 是实际命中测试数。

最有价值的实验与源码细节： coretests 含 2,787 个测试，在热增量缓存下执行 --exact char::test_is_numeric，总时间从 7.606s 降到 6.484s，节省 1.122s，约 14.8%。作者说明总时间的大头仍在 rustc，因此对 libtest/Miri 解释器准备阶段而言，实际相对改善比 14.8% 更大。

if opts.filter_exact && order == TestListOrder::Sorted {
    filter_exact_match(tests, &opts.filters)
}

for &idx in indexes.iter() {
    result.push(tests[idx].clone());
}

实现并非没有权衡：标准 test harness 和 merged rustdoc 可以直接生成静态数组；standalone rustdoc 的动态测试仍需构造引用 Vec，并把动态闭包从 Box<dyn FnOnce> 调整为可克隆的 Arc<dyn Fn>。这说明优化不是简单删除一次 clone，而是重新划清“静态目录”和“动态测试所有权”的接口边界。

适合的工程师背景： 熟悉 Rust test harness、Miri/nextest、rustdoc，或维护大型插件目录、路由表、测试注册表等“绝大多数调用只命中一个条目”的运行时框架工程师。

预计阅读收益： 约 30–45 分钟；可以学到如何沿调用链识别二分查找之前的隐藏 O(n) 成本，以及如何用借用视图、静态注册表和“只在命中后取得所有权”重构 API。

03 · Generational Shenandoah：先花 2–3ms 均分一百万个任务，再省掉百毫秒动态偷取

原文与日期： Aleksey Shipilev，2026-08-27；OpenJDK RFR 8391194，对应 JBS 8391194。

为什么值得读： 工作窃取通常被视为自动解决负载不均的通用方案，但当并发标记一开始就有极端倾斜的 remembered-set 工作量时，worker 会在热路径中不断竞争、偷取和搬运。这个补丁给出一个反直觉却很实用的结论：如果失衡在并行阶段开始前已经可见，串行或低并发地预平衡一次，可能远比运行中自适应恢复便宜。

核心技术结论： 新的 ShenandoahObjToScanQueueSet::rebalance() 先统计所有队列的 full_size()，按活动 worker 数计算目标长度；两次遍历把超额任务弹到临时栈，再填入不足队列，尾数以 round-robin 分发。它替代原来的 queue reservation 与 mark_drain_extra_queues()：后者只是让 worker 启动时领取额外队列，无法消除所有任务仍集中在少数队列、随后依赖昂贵 work stealing 扩散的问题。

size_t target_size = total / target_queues;
size_t to_pop  = (q_size > target_size) ? q_size - target_size : 0;
size_t to_push = (q_size < target_size)
               ? MIN2(ts.size(), target_size - q_size) : 0;

最有价值的实验、源码与 GC 日志证据： 在 8GiB heap、Generational Shenandoah、刻意制造不均衡队列的 Retain.java 3000 50 500 中，稳定阶段的 Concurrent Young GC 从约 136–157ms 降到约 57–64ms，作者概括为超过 2.5 倍改善。一次移动约 100 万个 mark task 的预平衡通常只花 2.2–2.8ms，而更均衡的队列避免了超过 100ms 的动态 work-stealing 成本；队列为空或已均衡时开销低于 5µs。最终标记虽然位于 safepoint，但通常队列为空，只有确有残余工作时才需要重排。

这不是“所有 GC 都应关闭工作窃取”的结论：预平衡解决的是起点已知的宏观偏斜，PR #32556 的 overflow queue eager drain 仍用于运行中突然出现的局部尖峰。两者分别对应 phase-boundary balancing 与 online recovery。

适合的工程师背景： 熟悉 Shenandoah/G1 并行标记、remembered set、任务队列和 work stealing，或正在设计图遍历、并行编译、分片批处理调度器的 JVM/运行时工程师。

预计阅读收益： 约 30–40 分钟；能获得一套调度判断框架：先区分“阶段开始前可观测的偏斜”和“运行中突发偏斜”，再比较一次性搬运成本、热路径竞争与 safepoint 预算，而不是默认把所有均衡责任交给动态窃取。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-07 下旬至 2026-08-28，单位人民币。8 月 28 日截稿前没有取得六个代表 SKU 的新同口径公开成交记录，因此沿用最近可复核的 8 月 25–26 日快照，不把抓取日期冒充变价日期，也不补造逐日行情。下图仍覆盖 CPU、GPU、主板、DRAM、HDD、SSD 六类独立价格折线；横线表示公开快照间未观察到变价，不代表每天都以该价格成交。

价格来源与复核状态： 9800X3D 与 9850X3D 国内同日价差、9800X3D 历史价格摘要、RTX 5070 商品百科、B850M 商品百科、8 月 26 日 B850M 市场样本、Kingston Fury 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。8 月 28 日重新检查时，MyDrivers 原文可访问，什么值得买商品页仍返回可用页面状态；慢慢买页面在本次抓取中超时，因此只沿用前一期已经核验的历史节点，不据此生成新价格。

判断依据

CPU 建议基于同平台同日价差：旧款与新款只差约 ¥120 时，没有必要为 9800X3D 的短促回弹价买单。GPU、DRAM 与 SSD 的公开快照仍未出现连续下行，不能把单次券价解释为供给趋势反转。主板不直接消耗显存或 NAND 颗粒，同芯片组跨品牌促销差异已明显大于时间趋势，故更适合按功能和售后选购。HDD 则更受企业容量需求与长单影响，建议以容量告警为触发条件分批购买。

其它你可能关心的

• Generational Shenandoah：overflow queue 从一次取一个任务改为更积极排空，以处理运行中突发偏斜
• OpenJDK：JFR epoch shift 锁范围可能与 NMT 虚拟内存锁形成锁序反转

本期结论

三篇材料表面上分别属于借用检查、测试框架与 GC，底层却是同一个工程问题：不要让“通用动态机制”掩盖可提前利用的结构信息。Polonius 已知借用维度极低，就不应为每个程序点保留小对象；--exact 已知只命中少量测试，就不应先复制整个目录；并发标记开始前已经看见队列倾斜，就不应等 worker 在热路径中反复偷取。优化的共同方法是把已知信息前移到布局、过滤或 phase boundary，同时保留负指标与适用边界。