Tokio 就绪态捷径与 HotSpot BSD 移植边界

本期检索说明

先读取 content/collections/deep-radar 截至 2026-09-10 的全部原文链接，并按 URL、标题与问题语义去重。本期最近 24 小时内，OpenJDK 的 BSD 移植草案与 rustc hygiene 稳定哈希优化满足源码、实测和机制三项要求；Tokio accepted socket readiness 修改发布稍早，但在 9 月 10 日完成评审合入，且给出了本周期最完整的线上复现、Criterion、过载延迟矩阵与 strace 证据，因此回溯纳入最近 7 天窗口。

Kotlin/Native 的“省略平凡函数 safepoint”只有代码生成设计与测试，尚无公开性能数据；Zig 与独立 Linux 主题也未发现同时满足三项红线且未被历史报告收录的新材料。本期不以发布说明或浅层候选补位。OpenJDK BSD 工作仍是 Draft，且 OCA、JBS、冲突和评审要求均未完成；本文分析的是公开移植实验，不把它写成已经进入主线的支持承诺。

01 · OpenJDK：BSD 移植不是改一个平台宏，而是逐层核对操作系统契约

原文与日期： zakinko，2026-09-11 07:37（中原标准时间）；openjdk/jdk PR #32829。该草案包含 22 个提交、143 个文件、7,789 行新增与 263 行删除，测试与限制均由作者在 PR 正文公开。

为什么值得读： OPENJDK_TARGET_OS=bsd 长期实际上只代表 macOS；目录名看似通用，内部却依赖 Mach、Darwin 的线程和动态链接接口。这个移植没有用一层条件编译掩盖差异，而是把构建系统、HotSpot、java.base 原生代码、Serviceability Agent、测试库和 CI 逐层拆开，暴露“名字相同的 POSIX 能力并不具有相同语义”。它尤其适合用来检查跨 Unix 代码中那些编译能过、运行时才会失败的隐含契约。

核心技术结论： 四种 BSD 需要的不是同一组替代 API。HotSpot 的线程 CPU 时间、模块枚举、CPU load、线程 ID 和可执行文件路径分别落到不同的 sysctl、pthread 与 dl_iterate_phdr 组合；固定地址内存保留在 FreeBSD 使用 MAP_FIXED | MAP_EXCL，DragonFly 使用 MAP_TRYFIXED。OpenBSD 的 primordial thread 栈拒绝 mprotect，因此由内核保留其 guard；其 pthread_getcpuclockid 会解引用已经终止的 pthread_t，clock id 必须在线程存活时取得。

构建侧同样有真实语义差异：OpenBSD 的 retguard 会在函数序言放入 VM 信号处理无法承受的 int3，移植暂用 -fno-ret-protector；DragonFly 的动态加载器只有在设置 DF_ORIGIN 时才展开 RPATH 中的 $ORIGIN，因此需要 -z origin。Serviceability Agent 在 FreeBSD/NetBSD 可沿 ELF 与 core 文件工作，但 OpenBSD 的 kinfo_vmentry 不提供映射文件路径，DragonFly 又缺少对应结构，所以草案明确让 Platform.hasSA() 返回 false，而不是提供残缺实现。

// “在固定地址保留内存”在不同 BSD 上不是同一个 flag 组合
FreeBSD:  MAP_FIXED | MAP_EXCL
DragonFly: MAP_TRYFIXED

// 对无法可靠枚举映射来源的平台，SA 直接声明不可用
if (isOpenBsd() || isDragonFly()) {
    return false;
}

最有价值的实验、源码与测试细节： NetBSD 11.0/amd64 与 FreeBSD 15.1-RELEASE-p3 的原生 tier1 都是 0 failure；GhostBSD 26.1 留下 1 个高负载下超时、单独运行可通过的失败；OpenBSD 7.9/amd64 留下 4 个失败，其中两个撞到默认 datasize rlimit、一个超时、一个是约 12 次出现一次的 NMT gtest 波动。四个目标的 Linux sysroot 交叉构建均为绿色，耗时约等于现有 Linux build。

DragonFly 暴露了更有价值的负向结果：KERN_PROC_PATHNAME 查询正在退出的进程会触发可由非特权用户稳定复现的内核 panic。作者给出复现和一行内核修复，并连续运行 50,000 轮未再出现 panic；但仍保留 rtld dlclose assert 与间歇性 C2 bailout，没有宣称 tier1 已干净通过。前置 15 个独立修复还发现 abs(jlong) 被截成 int、AlignmentSolver 除数乘积溢出、ctype 越界调用等并非 BSD 专属的问题，说明新平台最有价值的产物之一是让主流编译器和 libc 没碰到的未定义行为显形。

适合的工程师背景： 维护 HotSpot/JNI 原生层、跨 Unix runtime、内存映射、进程诊断或交叉编译工具链的工程师。

预计阅读收益： 约 60–90 分钟；能得到一份跨 OS 移植审计清单：区分 API 存在性与语义、在线程生命周期内缓存脆弱句柄、验证固定地址映射、对诊断能力明确降级，并把原生运行与 sysroot 交叉构建分开验收。

02 · Tokio：accepted socket 的第一次 I/O 不必先绕一圈 driver

原文与日期： so-ant，2026-09-09 21:33（中原标准时间）；tokio-rs/tokio PR #8435，于 2026-09-10 23:52（中原标准时间）合入。PR 的 3 个提交覆盖 readiness 位修复、实现、11 个文件中的测试与 benchmark。

为什么值得读： TcpListener::accept 返回的 socket 在内核里往往已经可写，客户端也常在服务端真正执行 accept 前发送完请求或 TLS/HTTP2 preface；但 Tokio 旧路径不给新 ScheduledIo 缓存任何 readiness，第一次 poll_read/poll_write 仍要等 I/O driver 投递事件。空闲时只是一次 driver turn，过载时却可能排在全部存量连接事件之后。文章难得之处在于同时给出能证明机制的 syscall 序列、微基准、过载实验和会变慢的反例。

核心技术结论： 新的 Registration::assume_ready 在 new_accepted 路径把 READABLE | WRITABLE 写入 ScheduledIo。readiness 本来就允许 false positive：第一次 syscall 若返回 WouldBlock，正常清除此位并回到 driver 等待，因此错误预测的成本是一轮 EAGAIN，不会破坏 edge-triggered 语义。修改只作用于 accept；connect、from_std 和 from_raw_fd 对 socket 状态没有同样的先验，不应套用。

旧路径：accept4 → epoll_ctl(ADD) → epoll_wait → recvfrom = 5 → sendto = 5
新路径：accept4 → epoll_ctl(ADD) →              recvfrom = 5 → sendto = 5

该实现还先修了一个潜在挂起：旧 set_readiness 只由 tick 与 readiness 重建 packed word，driver shutdown 后若再 clear_readiness，会把 shutdown bit 一并丢掉，使下次等待无法返回 shutdown error。预置 readiness 会把这条罕见路径变成常见路径，因此补丁先保证只改就绪位、不破坏生命周期状态。

最有价值的实验、源码与 benchmark 细节： 生产复现中，饱和 HTTP/2 服务的 accepted socket 从 accept4 到第一次 recvfrom 等待 64–128 ms，且 5,298/5,298 次 recvfrom 都立即读到数据。Criterion 的 busy-1024 inline-first-read 从 442/469/470 μs 降到 257/252/257 μs，约降低 45%；max_io_events_per_tick(8) 的 task-per-connection 从 1.96/2.23 ms 降到 1.33/1.44 ms。默认 task-per-connection 因 handler 真正运行前 driver 通常已经投递事件，结果在 0.82–1.82 ms 与 0.94–2.26 ms 间摆动，没有一致收益，作者没有把噪声写成提升。

更接近线上压力的实验把四 worker runtime 限制到两个 CPU、建立长连接 streaming 负载，并以每秒 50 个新连接测 connect 到首帧。在 1.7 倍容量负载下，p50/p99/max 从 130/226/278 ms 降到 59/160/179 ms；0.9 倍容量下 p50 不变为 0.9 ms，但 p99 从 14 降到 8 ms。已建立 stream 的 TTFB 未回退，1.7C 时 p50 反而从 702 降到 617 ms，queue-overflow 计数不变。负向边界同样明确：空闲的多 worker runtime 上，串行 accept-and-serve 可能因失去原先的自然 yield 而触发跨 CPU 唤醒，在昂贵 VM 上可接近 2 倍变慢。

适合的工程师背景： 熟悉 Tokio/mio、epoll readiness、HTTP/2 代理或正在排查新连接尾延迟与事件预算耦合的 Rust 网络工程师。

预计阅读收益： 约 50–70 分钟；可迁移的不是“总是预置 ready”，而是如何用内核可证明的先验做一次乐观 I/O、用 WouldBlock 恢复正确性，并分别测量 idle、事件队列饱和和业务过载三种调度形态。

03 · Rustc：稳定哈希只进入一次 hygiene 数据区

原文与日期： xmakro，2026-09-10 10:08（中原标准时间）；rust-lang/rust PR #162571 与 rustc-perf 对比。截稿时 PR 仍开放，评审已确认实现方向但尚未合入。

为什么值得读： SyntaxContext 的 stable hash 处在增量编译与宏 hygiene 的高频路径。旧代码先通过一次 HygieneData::with 取 outer_mark，再让 ExpnId::stable_hash 重新进入 hygiene 数据区取 stable expansion hash。新实现没有换哈希算法，只把同一逻辑内联到一次数据访问中，减少线程局部数据访问或锁边界的重复成本。

核心技术结论： patch 在一次 HygieneData::with 闭包中取得 (expn_id, transparency)，随即解析 data.expn_hash(expn_id).0；退出数据区后只对稳定 hash 值与 transparency 做序列化。hcx.assert_default_stable_hash_controls("ExpnId") 保留了原 ExpnId::stable_hash 对默认控制状态的断言，说明优化不是绕过稳定性约束，而是复制相同语义、减少一次进入数据结构的往返。

let (hash, transparency) = HygieneData::with(|data| {
    let (expn_id, transparency) = data.outer_mark(*self);
    (data.expn_hash(expn_id).0, transparency)
});
hash.stable_hash(hcx, hasher);
transparency.stable_hash(hcx, hasher);

最有价值的实验、源码与 benchmark 细节： 单文件改动只有 7 行新增、8 行删除。rustc-perf 的 27 个显著主样本指令数平均改善 0.3%，范围 0.1%–0.5%，没有显著指令回退；28 个次样本平均改善 0.2%。Max RSS 主样本汇总改善 0.1%，但一项回退 0.7%、一项改善 0.8%；cycles 主样本均值为 0.0%，仍同时存在最高 3.1% 回退和 1.1% 改善，说明墙钟相关计数噪声明显高于 instructions。bootstrap 从 480.118 秒降到 479.814 秒（-0.06%），artifact size 增加 0.01%。因此可确认的是稳定热路径的指令减少，不应扩张为可感知的全局编译时间承诺。

适合的工程师背景： 熟悉 rustc 宏展开、hygiene、增量编译 stable hashing，或在编译器中维护共享表与高频序列化路径的工程师。

预计阅读收益： 约 30–45 分钟；能学到怎样识别“同一抽象 API 在内部重复进入共享数据区”的小成本，并用稳定指令计数、内存、cycles 与 bootstrap 互相约束结论。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-08-13 至 2026-09-11，单位人民币。六类硬件继续固定同一 SKU。9 月 11 日复核时，既有六个公开比价入口均返回超时或验证码，搜索结果也不能提供同型号、同渠道、可核验日期的新人民币报价，因此本期不新增价格点，更不复制 9 月 10 日数据冒充当日采样。图表以 9 月 11 日为观察窗口终点，每条线只连接 JSON 中的真实日期点，面板“最新”仍指向该 SKU 最后一次有效观测。

价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。GPU 方向仍参考 2026-07-27 的中国区 RTX 50 系列渠道调价记录。

判断依据

价格建议只依据固定 SKU 的真实报价事件。CPU 与主板已经出现明确台阶式下降，可以在刚需时关注入手；GPU、HDD 的固定样本仍横盘，DRAM 没有持续下跌点。SSD 的 ¥749 与同一聚合页其他渠道价差过大，必须先验证容量、颗粒、保修与商家。由于 9 月 11 日没有任何新点，本期所有建议都保持条件式表达，不用“今天没涨”推导供需方向。

其它你可能关心的

• Kotlin/Native：为平凡 getter、setter 与 unboxing 函数省略 safepoint
• Tokio：让 io_uring QEMU 测试以完成标记识别 OOM 后的假绿
• Rustc：实验性优化 span 的 collect_pos

本期结论

三篇材料都在减少“抽象层为了保守正确性而支付的额外往返”，但采用了不同的安全边界：OpenJDK 先承认四种 BSD 的系统调用和诊断能力并不等价；Tokio 只对具有内核先验的 accepted socket 乐观预置 readiness，并保留 WouldBlock 回退；rustc 则在不改变稳定哈希语义的前提下合并两次 hygiene 数据访问。共同点是同时公开正向数据和失败边界，足以让结论迁移到别的 runtime、编译器或平台端口。