Shenandoah 巨型对象退化回收与 AVX-512 掩码合并

本期检索说明

先读取 content/collections/deep-radar 中截至 2026-09-01 的全部原文链接，并按 URL、标题和技术问题语义去重。最近 24 小时内最终只有 2 篇 OpenJDK 材料同时具备实测、源码证据、原理解释和工程迁移价值，因此没有用版本说明、旧文章或只有正确性测试的补丁凑数。Kotlin、Rust、Zig 与 Linux 在本周期内没有达到全部硬门槛的新增材料。

两项修改都仍处于 OpenJDK 公开评审阶段，本文分析的是可复核的补丁与 benchmark 提案，不把它们写成已合入 JDK 的既成事实。

主题	原始发布日期	一手来源与交叉验证	截稿状态	推荐强度
Generational Shenandoah 巨型对象分配失败的升级路径	2026-09-02（中原标准时间）	OpenJDK PR / JBS / HotSpot 源码与 GC 日志	Draft，未合入	必读
AVX-512 `VectorMask.eq` 的单指令归并	2026-09-01（中原标准时间）	OpenJDK PR / JBS / Webrev / JMH 与 IR 测试	Open，未合入	必读

01 · JVM：巨型对象分配失败不必立刻付出一次 Full GC

原文与日期： pf0n，2026-09-02 05:12（中原标准时间）；OpenJDK PR #32631，问题追踪见 JDK-8391591。

为什么值得读： 这是一处仅删除三行条件判断、却直接改变最坏延迟的 GC 控制路径。Generational Shenandoah 遇到 humongous allocation failure 时，现有代码即使允许 degenerated cycle，也会因专门条件直接转向 Full GC。补丁没有放宽所有失败场景，而是只取消“巨型对象失败必须跳过退化回收”的例外，并继续让老年代 evacuation failure 直接升级，因而很适合观察并发收集器如何设计分级故障恢复。

核心技术结论： 巨型对象需要连续 region，分配失败不等价于整个堆已经没有可回收空间。degenerated cycle 可以在 STW 下接管正在进行的回收状态，先尝试完成标记、疏散与整理；如果连续退化仍无法恢复，策略层仍可升级为 Full GC。补丁因此不是“取消 Full GC”，而是把它从第一次 humongous failure 的固定动作改成后续兜底动作。

控制线程的实质改动是从退化条件中移除 request.cause 的特殊排除：

-  if (ShenandoahDegeneratedGC && heuristics->should_degenerate_cycle() &&
-      !old_gen_evacuation_failed &&
-      request.cause != GCCause::_shenandoah_humongous_allocation_failure) {
+  if (ShenandoahDegeneratedGC && heuristics->should_degenerate_cycle() &&
+      !old_gen_evacuation_failed) {
     heuristics->record_allocation_failure_gc();
     return stw_degenerated;

最有价值的实验、源码与 benchmark 细节： 作者报告的单次请求 p100 延迟均值从 2.2 秒降至 124 毫秒，下降约 94.36%，即最坏延迟约缩短 17.7 倍。GC 日志先出现 Handle Allocation Failure，随后完成 degenerated: Humongous Allocation Failure, Young；回到 idle 后又因分配速率与预计 GC 时长触发一次正常并发 Young GC。这个序列说明新路径不是简单吞掉失败，而是先用退化周期恢复分配能力，再让并发调度重新接管。补丁同时通过 hotspot_gc_shenandoah 的 Linux x86_64 fastdebug 测试和内部 CI。

公开数据仍有边界：PR 只给出 p100 均值，未披露样本量、堆大小、对象尺寸分布和硬件配置，且改动尚未合入。因此 94.36% 只能视为该 workload 的故障路径收益，不能外推为 Shenandoah 常态吞吐提升。

适合的工程师背景： 维护 Shenandoah/G1/ZGC、追查 humongous object 尾延迟，或正在为并发 GC 设计“并发失败 → 退化 STW → Full GC”升级策略的 JVM 工程师。

预计阅读收益： 约 20–30 分钟；最可迁移的做法是把分配失败按“连续空间不足、疏散失败、全堆耗尽”分类，为每类失败保留逐级恢复路径，并以 p99/p100 与 GC 状态转换日志验证，而不是只看平均暂停。

02 · C2：把 `VectorMask.eq` 的 KNOT + KXOR 合并为一条 KXNOR

原文与日期： Jatin Bhateja，2026-09-01 16:52（中原标准时间）；OpenJDK PR #32622，交叉验证见 JDK-8390751 与第 00 版 Webrev。

为什么值得读： 这篇把 Vector API 的高级相等比较一路追到 C2 Ideal graph、x86 matcher、MacroAssembler 和最终 AVX-512 opmask 指令。它不是泛泛说“少一条指令更快”，而是给出四种 lane 类型的 JMH 吞吐、专门的 IR 断言和编码层实现，是阅读 C2 peephole/规则匹配优化的紧凑案例。

核心技术结论： VectorMask.eq 在 C2 中形成 XorVMask(m1, XorVMask(m2, MaskAll(-1)))，旧后端先把一个输入按位取反，再异或，生成 KNOT + KXOR。AVX-512 的 KXNOR 本身就计算 ~(src1 ^ src2)，因此新规则直接匹配整棵子图。补丁还要求内层 XorVMask 只有一个输出，避免为共享节点做破坏性归并。

核心 matcher 规则把“全一掩码参与的嵌套异或”映射到单条指令：

instruct mask_xnor_evex(kReg dst, kReg src1, kReg src2, immI_M1 m1) %{
  match(Set dst (XorVMask src1 (XorVMask src2 (MaskAll m1))));
  effect(TEMP_DEF dst);
  format %{ "kxnor  $dst,$src1,$src2\t! xnor opmask" %}
  ins_encode %{
    __ kxnor(this->ideal_Opcode(), $dst$$KRegister,
             $src1$$KRegister, $src2$$KRegister);
  %}
%}

Assembler 层新增 kxnordl、kxnorql 等编码，MacroAssembler 再按 BasicType 选择 byte/short/int/long 版本；因此优化不是只在图上声称完成，而是贯穿到实际机器码发射。

最有价值的实验、源码与 benchmark 细节： 在 128 核 AMD EPYC 9755 Turin、固定 2.5GHz、mask size 256 的 MaskLogicOperationsBenchmark 上，吞吐分别为：byte 159,974.636 → 182,394.071 ops/ms（+14.0%），short 106,759.600 → 126,642.157（+18.6%），int 53,170.370 → 89,680.615（+68.7%），long 32,048.635 → 47,342.562（+47.7%）。测试还为 byte/short/int/long 及等价 xor 写法设置 10,000 次预热，并在 FINAL_CODE 阶段断言 X86_MASK_XNOR = 1，把性能结果与目标指令直接绑定。

局限同样清楚：公开表格每项仅 Cnt=2，没有误差列，且只覆盖一台支持 AVX-512 的 Turin；不同 JDK 启动参数、频率策略和 Intel 微架构上的绝对收益仍需复测。最稳健的结论是“后端确实少发一条 opmask 指令，当前平台四组吞吐均改善”，不是所有工作负载都会得到 14%–69% 提升。

适合的工程师背景： 熟悉 C2 Ideal graph、Vector API、x86 AD matcher 或正在用 JMH、IR Framework 与反汇编共同验证 SIMD 代码生成的编译器/性能工程师。

预计阅读收益： 约 35–45 分钟；可以直接复用一套验证链：先写代数等价式，再为共享节点加安全约束，补齐 assembler/MacroAssembler，最后用 IR 指令计数和多 lane benchmark 同时证明优化已落到机器码且没有只优化某一种类型。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-08-03 至 2026-09-02，单位人民币。截至本期截稿，尚未取得六个代表 SKU 的新同口径公开成交记录，因此沿用最近可复核的 8 月 25–26 日快照；没有把抓取日期冒充变价日期，也没有插值补齐逐日行情。下图六个面板分别对应 CPU、GPU、主板、DRAM、HDD、SSD，每一折点均为公开可追溯的实际报价。

中国大陆六类 PC 硬件近 30 天价格快照

类别	代表样本与最近可核验价	近 30 天走势	建议
CPU	Ryzen 7 9800X3D，8/26 约 ¥3,175	8/10 促销 ¥2,283，8/21 ¥2,597，随后明显回弹	观望；9850X3D 同日约 ¥3,295，仅贵约 ¥120，旧款当前缺少价格优势
GPU	万丽 RTX 5070 OC 12GB，8/25 约 ¥6,899	窗口低点约 ¥5,249，后段明显走高	观望；国内渠道仍处 7 月底涨价后的高位，非生产力刚需不追高
主板	B850M 同档样本，8/25 约 ¥1,298	原跟踪样本小幅回落；8/26 其他品牌出现 ¥799 促销	可按需入手；品牌间价差大于时间趋势，优先比较供电、M.2、网卡与售后
DRAM	Kingston Fury DDR5-6000 32GB，8/25 约 ¥3,900	8/7 约 ¥3,870，高位横盘	刚需小量买，不囤；9/1 渠道参考价仍持平，尚无连续下行信号
HDD	IronWolf Pro 8TB，8/25 约 ¥1,540.7	可核验快照持平	容量告警时分批买；不要把一次促销当成供给趋势反转
SSD	ZHITAI Ti600 2TB，8/25 约 ¥749	7/26 至最近快照持平	刚需可买但不囤；9/1 NAND 与渠道 SSD 参考价持平，缺少持续回落证据

零售价格来源： 9800X3D 与 9850X3D 国内同日价差、9800X3D 历史价格摘要、RTX 5070 商品百科、B850M 商品百科、8 月 26 日 B850M 市场样本、Kingston Fury 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。

判断依据

经济日报 8 月 14 日的华强北走访记录了 7 月 24 日起显卡快速拉涨、7 月 27 日后高位趋稳：RTX 5060 从约 ¥2,300–2,500 升至约 ¥3,000，RTX 5070 Ti 从约 ¥6,000 升至 ¥8,000 以上。这与跟踪样本的后段抬升一致，因此 GPU 仍建议观望，而不是把“涨幅收窄”解释为降价。

存储侧，闪存市场 9 月 1 日报价显示 1Tb QLC/TLC NAND 日报价分别持平于 $26.50/$29.00，DDR5 UDIMM 8GB 5600/6000 与 16GB 5600 周报价也维持 $87/$92/$175；渠道 PCIe 4.0 SSD 的 1TB/2TB 周报价持平于 $130/$250。它们是美元计价的上游或渠道参考，不进入中国 ToC 折线，但至少没有给出持续下跌信号。CPU 建议仍基于同平台新旧型号即时价差；主板跨品牌促销差异已经大于短期时间趋势，适合按功能购买。

其它你可能关心的

Kotlin/Native：release compiler cache 丢失优化配置的修复提案

本期结论

两项优化都在重新审视“失败或高级操作应该怎样降级到机器层”。Generational Shenandoah 不再把第一次巨型对象分配失败直接等同于 Full GC，而是先尝试可恢复的退化周期；C2 则把高级掩码相等语义还原成布尔代数，最终落到一条 KXNOR。可迁移的共同方法是：先找出控制流或 IR 中多余的固定路径，再用状态日志或最终机器码证明路径确实改变，并同时公开 workload、硬件和样本量边界。